perm filename COMMON.7[COM,LSP] blob
sn#817327 filedate 1986-05-13 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00508 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00070 00002
C00071 00003 ∂13-Feb-86 0932 liz@brillig.umd.edu Re: loop macro
C00074 00004 ∂13-Feb-86 1041 RWK@SCRC-STONY-BROOK.ARPA Re: loop macro
C00076 00005 ∂13-Feb-86 1308 JAR@MC.LCS.MIT.EDU loop
C00077 00006 ∂13-Feb-86 1313 FAHLMAN@C.CS.CMU.EDU loop
C00079 00007 ∂13-Feb-86 1323 Gregor.pa@Xerox.COM load-time-eval
C00082 00008 ∂13-Feb-86 1342 FAHLMAN@C.CS.CMU.EDU load-time-eval
C00084 00009 ∂13-Feb-86 1433 NGALL@G.BBN.COM Re: load-time-eval
C00088 00010 ∂13-Feb-86 1514 Gregor.pa@Xerox.COM Re: load-time-eval
C00091 00011 ∂13-Feb-86 1744 RPG CL-ITERATION
C00092 00012 ∂14-Feb-86 0938 LOOSEMORE@UTAH-20.ARPA "include" revisited
C00095 00013 ∂14-Feb-86 1018 LOOSEMORE@UTAH-20.ARPA package system error handling
C00097 00014 ∂14-Feb-86 1137 Moon@SCRC-STONY-BROOK.ARPA package system error handling
C00101 00015 ∂14-Feb-86 1143 BSG@SCRC-STONY-BROOK.ARPA Re: loop macro
C00104 00016 ∂14-Feb-86 1607 hpfclp!hpfcdcm!dcm@hplabs.ARPA FUNCTION type specifier
C00107 00017 ∂14-Feb-86 1608 hpfclp!diamant@hplabs.ARPA Re: intern
C00112 00018 ∂15-Feb-86 2050 Miller.pa@Xerox.COM Re: loop macro
C00115 00019 ∂16-Feb-86 1711 FAHLMAN@C.CS.CMU.EDU intern
C00117 00020 ∂16-Feb-86 1717 FAHLMAN@C.CS.CMU.EDU FUNCTION type specifier
C00119 00021 ∂16-Feb-86 1746 GJC@MC.LCS.MIT.EDU forwared from CommonLoops
C00121 00022 ∂16-Feb-86 1753 RAM@C.CS.CMU.EDU intern
C00124 00023 ∂16-Feb-86 1853 SOLEY@MC.LCS.MIT.EDU forwared from CommonLoops
C00127 00024 ∂17-Feb-86 0811 shebs%utah-orion@utah-cs.arpa Basic Design Questions
C00132 00025 ∂17-Feb-86 1039 shebs%utah-orion@utah-cs.arpa Re: Basic Design Questions
C00135 00026 ∂17-Feb-86 1040 RAM@C.CS.CMU.EDU Basic Design Questions
C00139 00027 ∂17-Feb-86 1040 NGALL@G.BBN.COM Re: intern
C00146 00028 ∂17-Feb-86 1045 NGALL@G.BBN.COM Re: intern
C00150 00029 ∂17-Feb-86 1248 hpfclp!diamant@hplabs.ARPA intern
C00156 00030 ∂17-Feb-86 1912 FAHLMAN@C.CS.CMU.EDU Basic Design Questions
C00159 00031 ∂18-Feb-86 1540 fateman@dali.berkeley.edu value of *
C00161 00032 ∂18-Feb-86 1656 MOON@SCRC-STONY-BROOK.ARPA value of *
C00163 00033 ∂18-Feb-86 1657 FAHLMAN@C.CS.CMU.EDU value of *
C00165 00034 ∂18-Feb-86 1940 GJC@MC.LCS.MIT.EDU Basic Design Questions: function cells
C00168 00035 ∂19-Feb-86 0709 NGALL@G.BBN.COM Re: intern
C00174 00036 ∂19-Feb-86 0845 Swenson.Multics@CISL-SERVICE-MULTICS.ARPA Re: Basic Design Questions: function cells
C00177 00037 ∂19-Feb-86 1011 LOOSEMORE@UTAH-20.ARPA buffered output and prompting
C00181 00038 ∂19-Feb-86 1049 nelson%bizet.decnet@hudson.dec.com prompting
C00182 00039 ∂19-Feb-86 1113 MOON@SCRC-YUKON.ARPA Re: Basic Design Questions: function cells
C00186 00040 ∂19-Feb-86 1203 snyder@hplsny Re: Basic Design Questions: function cells
C00189 00041 ∂19-Feb-86 1239 gls@THINK-AQUINAS.ARPA Function cells
C00192 00042 ∂19-Feb-86 1240 MATHIS@USC-ISIF.ARPA Standardization proposal
C00194 00043 ∂19-Feb-86 1241 berman@isi-vaxa.ARPA Re: Basic Design Questions: function cells
C00197 00044 ∂19-Feb-86 1328 kessler%utah-orion@utah-cs.arpa re: Function Cells
C00199 00045 ∂19-Feb-86 1429 snyder@hplsny Re: Basic Design Questions: function cells
C00201 00046 ∂19-Feb-86 1618 Fischer.pa@Xerox.COM Re: transfer control to a random location
C00203 00047 ∂19-Feb-86 1809 GRISS@HP-HULK Re: Basic Design Questions: function cells
C00207 00048 ∂19-Feb-86 2146 pyramid!bein@sri-unix reading floats..
C00210 00049 ∂20-Feb-86 1002 @MCC.ARPA:ables%mcc-pp@mcc.arpa a note on back messages
C00212 00050 ∂20-Feb-86 1003 @MCC.ARPA:ables%mcc-pp@mcc.arpa back messages
C00234 00051 ∂20-Feb-86 1009 Cassels@SCRC-STONY-BROOK.ARPA reading floats..
C00238 00052 ∂20-Feb-86 1130 @MCC.ARPA:ables%dopey%mcc-pp@mcc.arpa apology
C00240 00053 ∂20-Feb-86 1315 Swenson.Multics@CISL-SERVICE-MULTICS.ARPA Re: Basic Design Questions: function cells
C00243 00054 ∂20-Feb-86 1335 FAHLMAN@C.CS.CMU.EDU Basic Design Questions: function cells
C00247 00055 ∂20-Feb-86 1505 DCP@ALLEGHENY.SCRC.Symbolics.COM loop macro
C00251 00056 ∂20-Feb-86 1521 DCP@ALLEGHENY.SCRC.Symbolics.COM Function cells
C00256 00057 ∂20-Feb-86 1540 RAM@C.CS.CMU.EDU buffered output and prompting
C00260 00058 ∂20-Feb-86 1653 GJC@MC.LCS.MIT.EDU Function cells
C00263 00059 ∂21-Feb-86 0949 NGALL@G.BBN.COM Re: buffered output and prompting
C00269 00060 ∂21-Feb-86 1127 LOOSEMORE@UTAH-20.ARPA Re: buffered output and prompting
C00272 00061 ∂21-Feb-86 1239 DCP@ALLEGHENY.SCRC.Symbolics.COM Function cells
C00275 00062 ∂21-Feb-86 1252 RAM@C.CS.CMU.EDU buffered output and prompting
C00277 00063 ∂21-Feb-86 1851 FAHLMAN@C.CS.CMU.EDU buffered output and prompting
C00279 00064 ∂21-Feb-86 1904 GJC@MC.LCS.MIT.EDU Function cells
C00281 00065 ∂22-Feb-86 1540 smh@mit-ems.ARPA reader # syntax and whitespace
C00284 00066 ∂22-Feb-86 2316 smh@mit-ems.ARPA readtable and # "syntax"
C00286 00067 ∂23-Feb-86 1037 FAHLMAN@C.CS.CMU.EDU reader # syntax and whitespace
C00288 00068 ∂23-Feb-86 1043 FAHLMAN@C.CS.CMU.EDU readtable and # "syntax"
C00291 00069 ∂24-Feb-86 0806 shebs%utah-orion@utah-cs.arpa Function Cell Follow-up
C00295 00070 ∂24-Feb-86 1109 JAR@MC.LCS.MIT.EDU Function Cell Follow-up
C00299 00071 ∂24-Feb-86 1200 DCP@ALLEGHENY.SCRC.Symbolics.COM Function Cell Follow-up
C00303 00072 ∂24-Feb-86 1256 DCP@ALLEGHENY.SCRC.Symbolics.COM Function Cell Follow-up
C00305 00073 ∂24-Feb-86 1820 JAR@MC.LCS.MIT.EDU Function Cell Follow-up
C00308 00074 ∂24-Feb-86 1858 shebs%utah-orion@utah-cs.arpa Re: Function Cell Follow-up
C00310 00075 ∂25-Feb-86 0816 DCP@ALLEGHENY.SCRC.Symbolics.COM Things to consider for CLtL'97
C00313 00076 ∂26-Feb-86 1027 ANDY@SU-SUSHI.ARPA defmacro in let
C00315 00077 ∂26-Feb-86 1520 JAR@MC.LCS.MIT.EDU What does LOAD use for read table & package?
C00318 00078 ∂26-Feb-86 1814 ANDY@SU-SUSHI.ARPA Re: defmacro in let
C00320 00079 ∂26-Feb-86 1820 NGALL@G.BBN.COM Re: defmacro in let
C00323 00080 ∂26-Feb-86 1828 FAHLMAN@C.CS.CMU.EDU What does LOAD use for read table & package?
C00328 00081 ∂27-Feb-86 0618 greek%bach.decnet@hudson.dec.com Loading into the current package.
C00331 00082 ∂27-Feb-86 0816 shebs%utah-orion@utah-cs.arpa Documentation Strings in Lambdas
C00333 00083 ∂27-Feb-86 0929 snyder@hplsny Re: What does LOAD use for read table & package?
C00336 00084 ∂27-Feb-86 1118 Moon@ALLEGHENY.SCRC.Symbolics.COM What does LOAD use for read table & package?
C00338 00085 ∂27-Feb-86 1529 kim@im4u.utexas.edu desperately seeking Lisp hackers
C00341 00086 ∂27-Feb-86 1741 FAHLMAN@C.CS.CMU.EDU What does LOAD use for read table & package?
C00344 00087 ∂28-Feb-86 0016 REM%IMSSS.#Pup@SU-SCORE.ARPA PACKAGE, READTABLE, etc. in compiled files vs. load uncompiled
C00346 00088 ∂28-Feb-86 0559 greek%bach.decnet@hudson.dec.com Collecting proposals for packages, readtables, etc.
C00349 00089 ∂28-Feb-86 0639 FAHLMAN@C.CS.CMU.EDU Environment Committee
C00353 00090 ∂28-Feb-86 0819 greek%bach.decnet@hudson.dec.com LISP Environment.
C00355 00091 ∂28-Feb-86 1006 JAR@MC.LCS.MIT.EDU Collecting proposals for packages, readtables, etc.
C00358 00092 ∂28-Feb-86 1039 gls@THINK-AQUINAS.ARPA Function cells
C00361 00093 ∂28-Feb-86 1127 @SCRC-QUABBIN.ARPA,@EUPHRATES.SCRC.Symbolics.COM:Moon@SCRC-STONY-BROOK.ARPA What does LOAD use for read table & package?
C00368 00094 ∂28-Feb-86 1144 gls@THINK-AQUINAS.ARPA Re: Function Cell Follow-up
C00371 00095 ∂28-Feb-86 1204 gls@THINK-AQUINAS.ARPA Things to consider for CLtL'97
C00375 00096 ∂28-Feb-86 1406 DCP@ALLEGHENY.SCRC.Symbolics.COM Things to consider for CLtL'97
C00380 00097 ∂28-Feb-86 1833 FAHLMAN@C.CS.CMU.EDU Collecting proposals for packages, readtables, etc.
C00382 00098 ∂28-Feb-86 2258 apollo!dfm@uw-beaver.arpa (satisfies predicate-name)
C00384 00099 ∂01-Mar-86 0528 GJC@MC.LCS.MIT.EDU What does LOAD use for read table & package?
C00387 00100 ∂01-Mar-86 2131 FAHLMAN@C.CS.CMU.EDU What does LOAD use for read table & package?
C00390 00101 ∂01-Mar-86 2325 RWK@ALLEGHENY.SCRC.Symbolics.COM Loading into the current package.
C00394 00102 ∂03-Mar-86 0440 GJC@MC.LCS.MIT.EDU What does LOAD use for read table & package?
C00396 00103 ∂03-Mar-86 0741 gls@THINK-AQUINAS.ARPA Things to consider for CLtL'97
C00401 00104 ∂03-Mar-86 1553 DCP@ALLEGHENY.SCRC.Symbolics.COM Things to consider for CLtL'97
C00406 00105 ∂03-Mar-86 1955 GJC@MC.LCS.MIT.EDU Things to consider for CLtL'97
C00408 00106 ∂04-Mar-86 0524 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Re: Environment Committee
C00411 00107 ∂04-Mar-86 0916 lab@rochester.arpa
C00415 00108 ∂04-Mar-86 1829 DCP@ALLEGHENY.SCRC.Symbolics.COM What is that -*- line for, anyway?
C00421 00109 ∂04-Mar-86 2017 GJC@MC.LCS.MIT.EDU What is that -*- line for, anyway?
C00424 00110 ∂05-Mar-86 0046 cfry%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU misc questions
C00426 00111 ∂05-Mar-86 0632 DCP@ALLEGHENY.SCRC.Symbolics.COM misc questions
C00429 00112 ∂05-Mar-86 0707 NGALL@G.BBN.COM Re: misc questions
C00433 00113 ∂05-Mar-86 1104 lab@rochester.arpa What is that -*- line for, anyway?
C00439 00114 ∂05-Mar-86 1925 FAHLMAN@C.CS.CMU.EDU Environment Committee
C00441 00115 ∂06-Mar-86 0631 NETS.NRTC@USC-ECL.ARPA Scope and declare
C00443 00116 ∂06-Mar-86 1207 liz@brillig.umd.edu Re: loop macro
C00445 00117 ∂06-Mar-86 1754 hpfclp!diamant@hplabs.ARPA get-setf-method
C00449 00118 ∂06-Mar-86 2059 apollo!dfm@uw-beaver.arpa initforms and implicit blocks
C00451 00119 ∂06-Mar-86 2118 DLW@ALLEGHENY.SCRC.Symbolics.COM What is that -*- line for, anyway?
C00454 00120 ∂06-Mar-86 2321 DLW@ALLEGHENY.SCRC.Symbolics.COM What is that -*- line for, anyway?
C00457 00121 ∂06-Mar-86 2321 apollo!dfm@uw-beaver.arpa initforms and implicit blocks
C00459 00122 ∂06-Mar-86 2334 RAM@C.CS.CMU.EDU initforms and implicit blocks
C00461 00123 ∂07-Mar-86 0625 DCP@ALLEGHENY.SCRC.Symbolics.COM get-setf-method
C00463 00124 ∂07-Mar-86 0659 greek%bach.decnet@hudson.dec.com The ~C format directive
C00465 00125 ∂07-Mar-86 0659 greek%bach.decnet@hudson.dec.com List of Changes
C00466 00126 ∂07-Mar-86 0727 gls@THINK-AQUINAS.ARPA What is that -*- line for, anyway?
C00468 00127 ∂07-Mar-86 0731 gls@THINK-AQUINAS.ARPA get-setf-method
C00470 00128 ∂07-Mar-86 0734 NGALL@G.BBN.COM Re: initforms and implicit blocks
C00474 00129 ∂07-Mar-86 0742 NGALL@G.BBN.COM Re: The ~C format directive
C00477 00130 ∂07-Mar-86 1004 JAR@MC.LCS.MIT.EDU Need for (declare (ignorable ...))
C00480 00131 ∂07-Mar-86 1020 greek%bach.decnet@hudson.dec.com IGNORABLE.
C00481 00132 ∂07-Mar-86 1038 DCP@ALLEGHENY.SCRC.Symbolics.COM Need for (declare (ignorable ...))
C00485 00133 ∂07-Mar-86 1043 WHOLEY@C.CS.CMU.EDU Need for (declare (ignorable ...))
C00490 00134 ∂07-Mar-86 1112 KMP@SCRC-STONY-BROOK.ARPA IGNORABLE
C00493 00135 ∂07-Mar-86 1200 franz!fimass!jkf@kim.berkeley.edu Re: Need for (declare (ignorable ...))
C00495 00136 ∂07-Mar-86 1206 DCP@ALLEGHENY.SCRC.Symbolics.COM Need for (declare (ignorable ...))
C00498 00137 ∂08-Mar-86 1216 preece%ccvaxa@gswd-vms Re: IGNORABLE.
C00499 00138 ∂08-Mar-86 1439 greek%bach.decnet@hudson.dec.com IGNORE and friends.
C00501 00139 ∂09-Mar-86 1140 shebs%utah-orion@utah-cs.arpa Re: ignorable
C00505 00140 ∂09-Mar-86 1434 SOLEY@MC.LCS.MIT.EDU IGNORABLE.
C00507 00141 ∂09-Mar-86 1540 KMP@SCRC-STONY-BROOK.ARPA TRUE, FALSE
C00510 00142 ∂09-Mar-86 1548 KMP@SCRC-STONY-BROOK.ARPA Can, could, may, might, must, ...
C00513 00143 ∂09-Mar-86 1557 KMP@SCRC-STONY-BROOK.ARPA (LOAD ... :VERBOSE T)
C00516 00144 ∂09-Mar-86 1614 KMP@SCRC-STONY-BROOK.ARPA Not just ~C, but ~A
C00519 00145 ∂09-Mar-86 1639 greek%bach.decnet@hudson.dec.com What's in the standard packages?
C00521 00146 ∂09-Mar-86 1639 KMP@SCRC-STONY-BROOK.ARPA *FEATURES*
C00525 00147 ∂09-Mar-86 1719 greek%bach.decnet@hudson.dec.com Putting the company name in the *FEATURES* list.
C00528 00148 ∂09-Mar-86 1723 GRISS%HP-HULK@hplabs.ARPA TRUE and FALSE as n-ary functions
C00529 00149 ∂10-Mar-86 0056 RAM@C.CS.CMU.EDU which package...
C00536 00150 ∂10-Mar-86 0643 FAHLMAN@C.CS.CMU.EDU LISP package
C00540 00151 ∂10-Mar-86 0715 FAHLMAN@C.CS.CMU.EDU True, False
C00542 00152 ∂10-Mar-86 0717 FAHLMAN@C.CS.CMU.EDU (LOAD ... :VERBOSE T)
C00545 00153 ∂10-Mar-86 0729 DCP@ALLEGHENY.SCRC.Symbolics.COM Can, could, may, might, must, ...
C00551 00154 ∂10-Mar-86 0737 GRISS%HP-HULK@hplabs.ARPA Packages
C00553 00155 ∂10-Mar-86 0742 shebs%utah-orion@utah-cs.arpa Re: LISP Package
C00555 00156 ∂10-Mar-86 0819 greek%bach.decnet@hudson.dec.com What packages contain.
C00557 00157 ∂10-Mar-86 0845 DCP@ALLEGHENY.SCRC.Symbolics.COM True, False
C00560 00158 ∂10-Mar-86 0851 DCP@ALLEGHENY.SCRC.Symbolics.COM What packages contain.
C00564 00159 ∂10-Mar-86 0906 DCP@ALLEGHENY.SCRC.Symbolics.COM LISP package
C00569 00160 ∂10-Mar-86 0939 greek%bach.decnet@hudson.dec.com One More Apology
C00571 00161 ∂10-Mar-86 0939 greek%bach.decnet@hudson.dec.com A package to contain Common LISP extensions.
C00573 00162 ∂10-Mar-86 0954 DCP@ALLEGHENY.SCRC.Symbolics.COM A package to contain Common LISP extensions.
C00576 00163 ∂10-Mar-86 1032 greek%bach.decnet@hudson.dec.com The LISP-EXTENSIONS Package.
C00578 00164 ∂10-Mar-86 1047 FAHLMAN@C.CS.CMU.EDU Lisp package
C00581 00165 ∂10-Mar-86 1111 JAR@MC.LCS.MIT.EDU A package to contain Common LISP extensions.
C00586 00166 ∂10-Mar-86 1135 REM@IMSSS Package for exactly CLtL and nothing else
C00589 00167 ∂10-Mar-86 1313 Dan@THINK-AQUINAS.ARPA Package for exactly CLtL and nothing else
C00592 00168 ∂10-Mar-86 1346 gls@THINK-AQUINAS.ARPA TRUE, FALSE
C00594 00169 ∂10-Mar-86 1431 FAHLMAN@C.CS.CMU.EDU TRUE, FALSE
C00596 00170 ∂10-Mar-86 1450 DCP@SCRC-STONY-BROOK.ARPA The LISP-EXTENSIONS Package.
C00599 00171 ∂10-Mar-86 1604 DCP@SCRC-QUABBIN.ARPA TRUE, FALSE
C00601 00172 ∂10-Mar-86 1604 GJC@MC.LCS.MIT.EDU "But that CONSES?"
C00603 00173 ∂10-Mar-86 1604 Gregor.pa@Xerox.COM Re: A package to contain Common LISP extensions.
C00607 00174 ∂10-Mar-86 1604 DCP@SCRC-QUABBIN.ARPA TRUE, FALSE
C00609 00175 ∂10-Mar-86 1731 KMP@SCRC-STONY-BROOK.ARPA The LISP-EXTENSIONS Package.
C00615 00176 ∂10-Mar-86 2020 NETS.NRTC@USC-ECL.ARPA Re Scope and declarations
C00619 00177 ∂10-Mar-86 2020 NETS.NRTC@USC-ECL.ARPA compiler-let and macrolet in macros
C00622 00178 ∂11-Mar-86 0707 gls@THINK-AQUINAS.ARPA TRUE, FALSE
C00624 00179 ∂11-Mar-86 0719 greek%bach.decnet@hudson.dec.com Where do extensions go?
C00627 00180 ∂11-Mar-86 0731 FAHLMAN@C.CS.CMU.EDU TRUE, FALSE
C00629 00181 ∂11-Mar-86 0757 gls@THINK-AQUINAS.ARPA TRUE, FALSE
C00632 00182 ∂11-Mar-86 0802 DLW@ALLEGHENY.SCRC.Symbolics.COM Meta-issue
C00634 00183 ∂11-Mar-86 0840 DLW@ALLEGHENY.SCRC.Symbolics.COM Where do extensions go?
C00639 00184 ∂11-Mar-86 0918 RPG TRUE, FALSE
C00640 00185 ∂11-Mar-86 1000 nelson%bach.decnet@hudson.dec.com package names
C00643 00186 ∂11-Mar-86 1003 greek%bach.decnet@hudson.dec.com Having lots of packages with extensions.
C00646 00187 ∂11-Mar-86 1058 DLW@ALLEGHENY.SCRC.Symbolics.COM TRUE, FALSE
C00650 00188 ∂11-Mar-86 1236 DLW@ALLEGHENY.SCRC.Symbolics.COM :if-does-not-exist
C00652 00189 ∂11-Mar-86 1357 Moon@ALLEGHENY.SCRC.Symbolics.COM compiler-let and macrolet in macros
C00656 00190 ∂11-Mar-86 1449 KMP@ALLEGHENY.SCRC.Symbolics.COM Some notes about declarations
C00659 00191 ∂11-Mar-86 1542 RAM@C.CS.CMU.EDU Which package...
C00662 00192 ∂11-Mar-86 1707 MMcM@ALLEGHENY.SCRC.Symbolics.COM TRUE, FALSE
C00664 00193 ∂11-Mar-86 1752 GJC@MC.LCS.MIT.EDU common lisp motto
C00665 00194 ∂12-Mar-86 0725 gls@THINK-AQUINAS.ARPA Some notes about declarations
C00669 00195 ∂12-Mar-86 0732 gls@THINK-AQUINAS.ARPA TRUE, FALSE
C00671 00196 ∂12-Mar-86 1102 berman@isi-vaxa.ARPA Validation Contributors
C00673 00197 ∂12-Mar-86 1129 DLW@ALLEGHENY.SCRC.Symbolics.COM Having lots of packages with extensions.
C00677 00198 ∂12-Mar-86 1407 JAR@MC.LCS.MIT.EDU Which package...
C00682 00199 ∂12-Mar-86 2212 mcvax!suna.psg.npl.co.uk!jrp@seismo.CSS.GOV Deletion from Mailing list
C00684 00200 ∂12-Mar-86 2317 GSB@MC.LCS.MIT.EDU Re: initforms and implicit blocks
C00686 00201 ∂13-Mar-86 0013 cfry%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU (LOAD ... :VERBOSE T)
C00689 00202 ∂13-Mar-86 0559 greek%bach.decnet@hudson.dec.com Package Naming Conventions
C00692 00203 ∂13-Mar-86 0744 DLW@ALLEGHENY.SCRC.Symbolics.COM (LOAD ... :VERBOSE T)
C00696 00204 ∂13-Mar-86 1031 FAHLMAN@C.CS.CMU.EDU (LOAD ... :VERBOSE T)
C00699 00205 ∂13-Mar-86 1148 DLW@ALLEGHENY.SCRC.Symbolics.COM (LOAD ... :VERBOSE T)
C00701 00206 ∂13-Mar-86 1446 MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA Packages
C00704 00207 ∂13-Mar-86 1537 KMP@SCRC-STONY-BROOK.ARPA (DELETE ... :COUNT NIL)
C00711 00208 ∂13-Mar-86 1654 NGALL@G.BBN.COM Re: (DELETE ... :COUNT NIL)
C00721 00209 ∂13-Mar-86 1715 Moon@ALLEGHENY.SCRC.Symbolics.COM Re: (DELETE ... :COUNT NIL)
C00723 00210 ∂13-Mar-86 2259 GSB@MC.LCS.MIT.EDU -*- lines
C00725 00211 ∂14-Mar-86 0432 GJC@MC.LCS.MIT.EDU Package Naming Conventions
C00728 00212 ∂14-Mar-86 0445 GJC@MC.LCS.MIT.EDU How many name spaces in CL?
C00730 00213 ∂14-Mar-86 0558 RAM@C.CS.CMU.EDU Packages
C00734 00214 ∂14-Mar-86 0751 FAHLMAN@C.CS.CMU.EDU How many name spaces in CL?
C00736 00215 ∂17-Mar-86 0124 cfry%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU How many name spaces in CL?
C00741 00216 ∂17-Mar-86 0841 shebs%utah-orion@utah-cs.arpa Namespaces
C00744 00217 ∂17-Mar-86 1935 FAHLMAN@C.CS.CMU.EDU Committee Membership for ANSI/ISO
C00753 00218 ∂17-Mar-86 2126 RPG Error handling proposal
C00754 00219 ∂18-Mar-86 0710 gls@THINK-AQUINAS.ARPA [CAL@THINK-AQUINAS.ARPA: packages and common lisp (yuk)]
C00757 00220 ∂18-Mar-86 0729 gls@THINK-AQUINAS.ARPA [ART@THINK-AQUINAS.ARPA: Another reader macro]
C00760 00221 ∂18-Mar-86 0740 FAHLMAN@C.CS.CMU.EDU [ART@THINK-AQUINAS.ARPA: Another reader macro]
C00763 00222 ∂18-Mar-86 0759 KMP@SCRC-STONY-BROOK.ARPA Error handling proposal
C00766 00223 ∂18-Mar-86 1125 Moon@ALLEGHENY.SCRC.Symbolics.COM [ART@THINK-AQUINAS.ARPA: Another reader macro]
C00769 00224 ∂18-Mar-86 1137 Moon@ALLEGHENY.SCRC.Symbolics.COM [CAL@THINK-AQUINAS.ARPA: packages and common lisp (yuk)]
C00772 00225 ∂18-Mar-86 1239 preece%ccvaxa@gswd-vms Re: [ART@THINK-AQUINAS.ARPA: Another
C00774 00226 ∂18-Mar-86 1343 DCP@ALLEGHENY.SCRC.Symbolics.COM Re: [ART@THINK-AQUINAS.ARPA: Another
C00777 00227 ∂18-Mar-86 1439 gls@THINK-AQUINAS.ARPA Re: [ART@THINK-AQUINAS.ARPA: Another
C00782 00228 ∂18-Mar-86 1454 FAHLMAN@C.CS.CMU.EDU [ART@THINK-AQUINAS.ARPA: Another
C00784 00229 ∂18-Mar-86 1721 Moon@ALLEGHENY.SCRC.Symbolics.COM Re: [ART@THINK-AQUINAS.ARPA: Another
C00787 00230 ∂18-Mar-86 1812 KMP@SCRC-STONY-BROOK.ARPA [ART@THINK-AQUINAS.ARPA: Another
C00790 00231 ∂19-Mar-86 0622 greek%bach.decnet@hudson.dec.com Ignoring a list.
C00792 00232 ∂19-Mar-86 0713 DCP@ALLEGHENY.SCRC.Symbolics.COM Ignoring a list.
C00795 00233 ∂19-Mar-86 1002 Gregor.pa@Xerox.COM Re: Ignoring a list.
C00798 00234 ∂19-Mar-86 1159 preece%ccvaxa@gswd-vms Re: Ignoring a list.
C00803 00235 ∂19-Mar-86 1434 Masinter.pa@Xerox.COM Re: Ignoring a list.
C00805 00236 ∂19-Mar-86 2056 α@uw-beaver.arpa
C00806 00237 ∂20-Mar-86 1327 MATHIS@USC-ISIF.ARPA SPARC Endorses X3J13
C00808 00238 ∂20-Mar-86 1415 DD60@A.CS.CMU.EDU Standardization
C00809 00239 ∂20-Mar-86 1537 DCP@ALLEGHENY.SCRC.Symbolics.COM Standardization
C00812 00240 ∂20-Mar-86 2315 cfry%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU Re: Ignoring a list.
C00818 00241 ∂21-Mar-86 0840 MATHIS@USC-ISIF.ARPA Re: Standardization
C00820 00242 ∂21-Mar-86 0952 gls@THINK-AQUINAS.ARPA Standardization
C00822 00243 ∂21-Mar-86 1023 FAHLMAN@C.CS.CMU.EDU Standardization
C00826 00244 ∂25-Mar-86 0306 liz@brillig.umd.edu Re: Standardization
C00829 00245 ∂25-Mar-86 1059 @MIT-ZERMATT.ARPA:Soley@MIT-MC.ARPA Re: Standardization
C00832 00246 ∂25-Mar-86 1059 JAR@MC.LCS.MIT.EDU Standardization
C00834 00247 ∂25-Mar-86 1141 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Re: Standardization
C00844 00248 ∂25-Mar-86 1206 gls@GODOT.THINK.COM Suggestions for language changes
C00846 00249 ∂25-Mar-86 1718 pyramid!pyrps5.bein@sri-unix comments...
C00849 00250 ∂25-Mar-86 1948 GJC@MC.LCS.MIT.EDU the Duck port you gave up on.
C00851 00251 ∂26-Mar-86 1501 DCP@ALLEGHENY.SCRC.Symbolics.COM inline declaration for FLET and LABELS
C00853 00252 ∂27-Mar-86 0855 PGS@AI.AI.MIT.EDU inline declaration for FLET and LABELS
C00856 00253 ∂27-Mar-86 1021 DCP@ALLEGHENY.SCRC.Symbolics.COM inline declaration for FLET and LABELS
C00861 00254 ∂27-Mar-86 1059 BROOKS%OZ.AI.MIT.EDU@AI.AI.MIT.EDU Re: inline declaration for FLET and LABELS
C00864 00255 ∂27-Mar-86 1133 JAR@MC.LCS.MIT.EDU inline declaration for FLET and LABELS
C00866 00256 ∂28-Mar-86 0823 NGALL@G.BBN.COM Predicates for all type specifier symbols
C00869 00257 ∂28-Mar-86 0901 DCP@ALLEGHENY.SCRC.Symbolics.COM Re: inline declaration for FLET and LABELS
C00874 00258 ∂28-Mar-86 0943 greek%bach.decnet@hudson.dec.com Predicates for types.
C00875 00259 ∂28-Mar-86 1202 Gregor.pa@Xerox.COM Re: Standardization
C00877 00260 ∂28-Mar-86 1208 RPG
C00879 00261 ∂28-Mar-86 1306 DICK%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU LetS -- a new loop notation
C00897 00262 ∂28-Mar-86 1436 Fischer.pa@Xerox.COM Re: Predicates for all type specifier symbols
C00898 00263 ∂28-Mar-86 2029 FAHLMAN@C.CS.CMU.EDU Predicates for all type specifier symbols
C00900 00264 ∂29-Mar-86 1255 NGALL@G.BBN.COM Re: Predicates for all type specifier symbols
C00904 00265 ∂29-Mar-86 1354 WHOLEY@C.CS.CMU.EDU Predicates for all type specifier symbols
C00908 00266 ∂29-Mar-86 1731 FAHLMAN@C.CS.CMU.EDU Predicates for all type specifier symbols
C00910 00267 ∂29-Mar-86 1852 Moon@SCRC-STONY-BROOK.ARPA Predicates for all type specifier symbols
C00912 00268 ∂31-Mar-86 0620 greek%bach.decnet@hudson.dec.com Type predicates.
C00914 00269 ∂31-Mar-86 0707 DCP@ALLEGHENY.SCRC.Symbolics.COM Predicates for types.
C00917 00270 ∂31-Mar-86 0750 gls@THINK-AQUINAS.ARPA Re: Predicates for all type specifier symbols
C00919 00271 ∂31-Mar-86 1134 neches@isi-vaxa.ARPA common-lisp on vaxes under vms?
C00921 00272 ∂31-Mar-86 1215 Daniels.PA@Xerox.COM Re: Predicates for all type specifier symbols
C00923 00273 ∂31-Mar-86 1252 NGALL@G.BBN.COM Re: Predicates for all type specifier symbols
C00925 00274 ∂31-Mar-86 1330 KMP@SCRC-STONY-BROOK.ARPA predicates for all type specifier symbols
C00930 00275 ∂31-Mar-86 1616 NGALL@G.BBN.COM Re: predicates for all type specifier symbols
C00937 00276 ∂01-Apr-86 0158 cfry%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU eval-when ambiguity
C00939 00277 ∂01-Apr-86 0619 greek%bach.decnet@hudson.dec.com EVAL-WHEN
C00943 00278 ∂01-Apr-86 0836 gls@THINK-AQUINAS.ARPA [CAL@THINK-AQUINAS.ARPA: declarations]
C00945 00279 ∂01-Apr-86 0846 gls@THINK-AQUINAS.ARPA [rose@GODOT.THINK.COM: option for recovering proclamations]
C00948 00280 ∂01-Apr-86 1428 Gregor.pa@Xerox.COM Common Lisp Problems - Can't write a code walker
C00953 00281 ∂02-Apr-86 0754 kempf%hplabsc@hplabs.ARPA Re:Common Lisp Problems-Can't write a code walker
C00956 00282 ∂02-Apr-86 0819 greek%bach.decnet@hudson.dec.com The Environment
C00958 00283 ∂02-Apr-86 0856 DCP@ALLEGHENY.SCRC.Symbolics.COM The Environment
C00962 00284 ∂02-Apr-86 0942 greek%bach.decnet@hudson.dec.com The Environment
C00964 00285 ∂02-Apr-86 1051 DCP@ALLEGHENY.SCRC.Symbolics.COM The Environment
C00968 00286 ∂02-Apr-86 2102 smh@mit-ems.ARPA packages, lexical variables, and compiling
C00972 00287 ∂03-Apr-86 0619 greek%bach.decnet@hudson.dec.com Lexical variables and compilation.
C00974 00288 ∂03-Apr-86 0750 gls@THINK-AQUINAS.ARPA Common Lisp Problems - Can't write a code walker
C00977 00289 ∂03-Apr-86 0754 gls@THINK-AQUINAS.ARPA [JAR@MC.LCS.MIT.EDU: changes]
C00982 00290 ∂03-Apr-86 0859 DCP@SCRC-RIVERSIDE.ARPA packages, lexical variables, and compiling
C00992 00291 ∂03-Apr-86 0953 DD60@A.CS.CMU.EDU internal symbol preservation
C00994 00292 ∂03-Apr-86 1034 Gregor.pa@Xerox.COM Re: packages, lexical variables, and compiling
C00997 00293 ∂03-Apr-86 1041 DCP@ALLEGHENY.SCRC.Symbolics.COM [JAR@MC.LCS.MIT.EDU: changes]
C01004 00294 ∂03-Apr-86 1214 DICK%OZ.AI.MIT.EDU@AI.AI.MIT.EDU
C01009 00295 ∂03-Apr-86 1230 greek%bach.decnet@hudson.dec.com Excuse me?
C01010 00296 ∂03-Apr-86 1609 Moon@SCRC-STONY-BROOK.ARPA EVAL-WHEN
C01018 00297 ∂03-Apr-86 1814 Bobrow.pa@Xerox.COM Re: EVAL-WHEN
C01020 00298 ∂03-Apr-86 1953 BROOKS%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU Re: EVAL-WHEN
C01022 00299 ∂04-Apr-86 0605 greek%bach.decnet@hudson.dec.com Dave Moon's summary of EVAL-WHEN issues.
C01024 00300 ∂04-Apr-86 0635 NGALL@G.BBN.COM Re: EVAL-WHEN
C01027 00301 ∂04-Apr-86 0741 DCP@ALLEGHENY.SCRC.Symbolics.COM Excuse me?
C01029 00302 ∂04-Apr-86 0741 DCP@ALLEGHENY.SCRC.Symbolics.COM Excuse me?
C01032 00303 ∂04-Apr-86 0802 gls@THINK-AQUINAS.ARPA EVAL-WHEN
C01035 00304 ∂04-Apr-86 0802 gls@THINK-AQUINAS.ARPA Re: EVAL-WHEN
C01039 00305 ∂04-Apr-86 1102 Bobrow.pa@Xerox.COM Re: Dave Moon's summary of EVAL-WHEN issues.
C01040 00306 ∂04-Apr-86 1256 jpg@ALLEGHENY.SCRC.Symbolics.COM EVAL-WHEN
C01042 00307 ∂04-Apr-86 1439 Pavel.pa@Xerox.COM Re: EVAL-WHEN
C01043 00308 ∂04-Apr-86 1452 WHOLEY@C.CS.CMU.EDU EVAL-WHEN
C01045 00309 ∂05-Apr-86 0745 hpfclp!diamant@hplabs.ARPA Re: EVAL-WHEN (really symbol-function)
C01051 00310 ∂05-Apr-86 1223 preece%ccvaxa@gswd-vms Re: EVAL-WHEN (really symbol-functio
C01055 00311 ∂05-Apr-86 1425 Bobrow.pa@Xerox.COM Re: Symbol-function
C01058 00312 ∂05-Apr-86 1513 DLW@SCRC-STONY-BROOK.ARPA Re: EVAL-WHEN (really symbol-function)
C01062 00313 ∂05-Apr-86 1651 HENRIK@MC.LCS.MIT.EDU common-lisp on vaxes under vms?
C01064 00314 ∂05-Apr-86 2308 hpfclp!diamant@hplabs.ARPA Re: Symbol-function
C01073 00315 ∂06-Apr-86 2101 RAM@C.CS.CMU.EDU EVAL-WHEN
C01078 00316 ∂07-Apr-86 0619 greek%bach.decnet@hudson.dec.com Top-level EVAL-WHEN
C01080 00317 ∂07-Apr-86 1246 gls@THINK-AQUINAS.ARPA Re: EVAL-WHEN (really symbol-function)
C01088 00318 ∂07-Apr-86 1531 Pavel.pa@Xerox.COM What can I redefine?
C01092 00319 ∂07-Apr-86 1540 RAM@C.CS.CMU.EDU Top-level EVAL-WHEN
C01095 00320 ∂07-Apr-86 1643 RAM@C.CS.CMU.EDU What can I redefine?
C01098 00321 ∂08-Apr-86 0707 greek%bach.decnet@hudson.dec.com EVAL-WHEN buried inside a form.
C01100 00322 ∂08-Apr-86 0749 DCP@SCRC-STONY-BROOK.ARPA What can I redefine?
C01102 00323 ∂08-Apr-86 0947 greek%bach.decnet@hudson.dec.com EVAL-WHEN buried inside forms.
C01104 00324 ∂08-Apr-86 1434 NGALL@G.BBN.COM Re: EVAL-WHEN (really symbol-function)
C01111 00325 ∂08-Apr-86 1505 NGALL@G.BBN.COM Extent of function definition created by FLET/LABELS
C01112 00326 ∂08-Apr-86 1754 DCP@SCRC-STONY-BROOK.ARPA Extent of function definition created by FLET/LABELS
C01115 00327 ∂08-Apr-86 1846 RWK@SCRC-STONY-BROOK.ARPA Extent of function definition created by FLET/LABELS
C01117 00328 ∂08-Apr-86 1924 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Re: Symbol-function
C01119 00329 ∂08-Apr-86 2325 RAM@C.CS.CMU.EDU EVAL-WHEN buried inside forms.
C01122 00330 ∂09-Apr-86 0509 smh@mit-ems.ARPA Re: What can I redefine?
C01125 00331 ∂09-Apr-86 0754 Swenson.Multics@CISL-SERVICE-MULTICS.ARPA Common Loops
C01126 00332 ∂09-Apr-86 0918 Swenson.Multics@CISL-SERVICE-MULTICS.ARPA Common Loops
C01127 00333 ∂09-Apr-86 1921 FAHLMAN@C.CS.CMU.EDU Dave Moon's summary of EVAL-WHEN issues.
C01130 00334 ∂10-Apr-86 0004 cfry%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU Dave Moon's summary of EVAL-WHEN issues.
C01134 00335 ∂10-Apr-86 0051 RAM@C.CS.CMU.EDU Successor to eval-when?
C01136 00336 ∂10-Apr-86 0655 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Re: EVAL-WHEN (really symbol-function)
C01143 00337 ∂10-Apr-86 0706 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Re: Extent of function definition created by FLET/LABELS
C01146 00338 ∂10-Apr-86 0816 gls@THINK-AQUINAS.ARPA Extent of function definition created by FLET/LABELS
C01148 00339 ∂10-Apr-86 0816 gls@THINK-AQUINAS.ARPA Extent of function definition created by FLET/LABELS: additional remark
C01150 00340 ∂10-Apr-86 0859 NGALL@G.BBN.COM Re: Extent of function definition created by FLET/LABELS: ad...
C01153 00341 ∂10-Apr-86 1005 NGALL@G.BBN.COM Re: EVAL-WHEN (really symbol-function)
C01161 00342 ∂10-Apr-86 2303 gls@THINK-AQUINAS.ARPA [gls@THINK-AQUINAS.ARPA: setf place]
C01164 00343 ∂10-Apr-86 2308 hpfclp!diamant@hplabs.ARPA Re: EVAL-WHEN (really symbol-function)
C01175 00344 ∂11-Apr-86 0706 DLW@SAPSUCKER.SCRC.Symbolics.COM Re: EVAL-WHEN (really symbol-function)
C01178 00345 ∂11-Apr-86 0801 NGALL@G.BBN.COM Re: SYMBOL-FUNCTION
C01188 00346 ∂11-Apr-86 0827 FAHLMAN@C.CS.CMU.EDU SYMBOL-FUNCTION
C01191 00347 ∂11-Apr-86 1339 greek%bach.decnet@hudson.dec.com Questions and an offer concerning "EVAL-WHEN" issues.
C01197 00348 ∂11-Apr-86 1342 NGALL@G.BBN.COM Are isomorphic structures EQUAL?
C01201 00349 ∂11-Apr-86 1716 hpfclp!diamant@hplabs.ARPA Re: SYMBOL-FUNCTION
C01203 00350 ∂11-Apr-86 1948 Pavel.pa@Xerox.COM unwind-protect
C01205 00351 ∂14-Apr-86 1337 cfry%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU Successor to eval-when?
C01208 00352 ∂14-Apr-86 1540 JAR@MC.LCS.MIT.EDU Are isomorphic structures EQUAL?
C01210 00353 ∂14-Apr-86 1630 GJC@MC.LCS.MIT.EDU
C01211 00354 ∂14-Apr-86 1632 cfry%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU Successor to eval-when?
C01214 00355 ∂14-Apr-86 1646 RPG sign me up
C01216 00356 ∂14-Apr-86 1723 DCP@SCRC-STONY-BROOK.ARPA unwind-protect
C01219 00357 ∂14-Apr-86 1812 gls@THINK-AQUINAS.ARPA unwind-protect
C01222 00358 ∂14-Apr-86 2117 DT50@A.CS.CMU.EDU bit fields in defstruct
C01226 00359 ∂15-Apr-86 0412 GJC@MC.LCS.MIT.EDU unwind-protect description
C01228 00360 ∂15-Apr-86 0417 GJC@MC.LCS.MIT.EDU contents of SYMBOL-FUNCTION for special forms.
C01230 00361 ∂15-Apr-86 0753 DCP@SCRC-QUABBIN.ARPA bit fields in defstruct
C01236 00362 ∂15-Apr-86 1028 LOOSEMORE@UTAH-20.ARPA block/tagbody and catch/throw
C01238 00363 ∂15-Apr-86 1113 RAM@C.CS.CMU.EDU block/tagbody and catch/throw
C01240 00364 ∂15-Apr-86 1124 Daniels.pa@Xerox.COM Re: unwind-protect description
C01242 00365 ∂15-Apr-86 1225 DCP@ALLEGHENY.SCRC.Symbolics.COM block/tagbody and catch/throw
C01247 00366 ∂15-Apr-86 1659 RAM@C.CS.CMU.EDU block/tagbody and catch/throw
C01252 00367 ∂16-Apr-86 0808 LOOSEMORE@UTAH-20.ARPA Re: block/tagbody and catch/throw
C01255 00368 ∂16-Apr-86 1325 hpfclp!paul@hplabs.ARPA
C01259 00369 ∂16-Apr-86 1652 somewhere!hagiya@kurims.kurims.kyoto-u.junet
C01263 00370 ∂16-Apr-86 1911 DSinger@SRI-KL.ARPA Integer Shift Function(s)
C01265 00371 ∂16-Apr-86 1930 FAHLMAN@C.CS.CMU.EDU Integer Shift Function(s)
C01267 00372 ∂16-Apr-86 2107 DT50@A.CS.CMU.EDU extending defstruct
C01271 00373 ∂17-Apr-86 0620 KMP@SCRC-STONY-BROOK.ARPA (PROCLAIM '(IGNORE ...))
C01273 00374 ∂17-Apr-86 0702 greek%bach.decnet@hudson.dec.com (PROCLAIM '(IGNORE ...))
C01275 00375 ∂17-Apr-86 0810 marchett%cod@nosc.ARPA slotp
C01278 00376 ∂17-Apr-86 0927 @SRI-KL.ARPA:gls@AQUINAS.THINK.COM Integer Shift Function(s)
C01281 00377 ∂17-Apr-86 1122 DCP@ALLEGHENY.SCRC.Symbolics.COM Integer Shift Function(s)
C01284 00378 ∂17-Apr-86 1123 DCP@ALLEGHENY.SCRC.Symbolics.COM extending defstruct
C01292 00379 ∂17-Apr-86 1434 Gregor.pa@Xerox.COM What is a compiler (vol. 63827) meets what are gensyms.
C01296 00380 ∂17-Apr-86 1610 DT50@A.CS.CMU.EDU Plummer wins
C01297 00381 ∂18-Apr-86 0648 FAHLMAN@C.CS.CMU.EDU What is a compiler (vol. 63827) meets what are gensyms.
C01299 00382 ∂18-Apr-86 0911 RAM@C.CS.CMU.EDU Plummer wins
C01303 00383 ∂18-Apr-86 0939 greek%bach.decnet@hudson.dec.com Bit fields in structures.
C01305 00384 ∂18-Apr-86 1324 NGALL@G.BBN.COM Type Specifier: (OR (FUNCTION ...) ...)
C01309 00385 ∂18-Apr-86 1946 KMP@SCRC-STONY-BROOK.ARPA slotp
C01312 00386 ∂18-Apr-86 1959 Moon@SAPSUCKER.SCRC.Symbolics.COM Should the floating-point constants really be constants?
C01318 00387 ∂18-Apr-86 2011 KMP@SCRC-STONY-BROOK.ARPA (PROCLAIM '(IGNORE ...))
C01327 00388 ∂18-Apr-86 2013 Moon@SCRC-STONY-BROOK.ARPA Should the floating-point constants really be constants?
C01333 00389 ∂19-Apr-86 0831 tansei!a37078%utokyo-relay.csnet@CSNET-RELAY.ARPA We are entering a new stage....
C01337 00390 ∂19-Apr-86 1307 FAHLMAN@C.CS.CMU.EDU (PROCLAIM '(IGNORE ...))
C01340 00391 ∂19-Apr-86 1322 FAHLMAN@C.CS.CMU.EDU Type Specifier: (OR (FUNCTION ...) ...)
C01343 00392 ∂19-Apr-86 1409 NGALL@G.BBN.COM Re: Type Specifier: (OR (FUNCTION ...) ...)
C01348 00393 ∂19-Apr-86 1440 NGALL@G.BBN.COM Re: (PROCLAIM '(IGNORE ...))
C01353 00394 ∂19-Apr-86 1537 SOLEY@MC.LCS.MIT.EDU (PROCLAIM '(IGNORE ...))
C01356 00395 ∂19-Apr-86 1612 NGALL@G.BBN.COM true-list type specifier
C01359 00396 ∂20-Apr-86 0742 FAHLMAN@C.CS.CMU.EDU true-list type specifier
C01361 00397 ∂20-Apr-86 0831 FAHLMAN@C.CS.CMU.EDU (PROCLAIM '(IGNORE ...))
C01367 00398 ∂20-Apr-86 0846 FAHLMAN@C.CS.CMU.EDU Type Specifier: (OR (FUNCTION ...) ...)
C01370 00399 ∂20-Apr-86 0949 NGALL@G.BBN.COM Re: true-list type specifier
C01374 00400 ∂20-Apr-86 1313 gls@THINK-AQUINAS.ARPA Re: Type Specifier: (OR (FUNCTION ...) ...)
C01380 00401 ∂20-Apr-86 1325 gls@THINK-AQUINAS.ARPA (PROCLAIM '(IGNORE ...))
C01383 00402 ∂20-Apr-86 1402 REM@IMSSS What really are semantics of (OR ...) type specifier??
C01387 00403 ∂20-Apr-86 1402 REM@IMSSS Need way to suppress warning messages after first see
C01394 00404 ∂20-Apr-86 1519 FAHLMAN@C.CS.CMU.EDU true-list type specifier
C01397 00405 ∂20-Apr-86 1759 meehan@YALE.ARPA ignore
C01399 00406 ∂20-Apr-86 1930 DT50@A.CS.CMU.EDU IGNORE, warnings, and &stuff
C01402 00407 ∂20-Apr-86 2019 FAHLMAN@C.CS.CMU.EDU IGNORE, warnings, and &stuff
C01405 00408 ∂21-Apr-86 0035 Moon@SCRC-STONY-BROOK.ARPA What is a compiler (vol. 63827) meets what are gensyms.
C01407 00409 ∂21-Apr-86 0106 DCP@ALLEGHENY.SCRC.Symbolics.COM What is a compiler (vol. 63827) meets what are gensyms.
C01412 00410 ∂21-Apr-86 0106 DCP@ALLEGHENY.SCRC.Symbolics.COM What is a compiler (vol. 63827) meets what are gensyms.
C01417 00411 ∂21-Apr-86 0722 @MIT-LIVE-OAK.ARPA:Soley@MIT-MC.ARPA IGNORE, warnings, and &stuff
C01420 00412 ∂21-Apr-86 0754 FAHLMAN@C.CS.CMU.EDU IGNORE, warnings, and &stuff
C01422 00413 ∂21-Apr-86 0828 KMP@SCRC-STONY-BROOK.ARPA [marchett%cod@nosc: slotp]
C01427 00414 ∂21-Apr-86 1031 meehan@YALE.ARPA *print-circle*
C01429 00415 ∂21-Apr-86 1314 mips!pachyderm.earl@su-glacier.arpa IGNORE, warnings, and &stuff
C01431 00416 ∂21-Apr-86 1334 NGALL@G.BBN.COM Re: Type Specifier: (OR (FUNCTION ...) ...)
C01439 00417 ∂21-Apr-86 1407 RZ@MIT-ZERMATT.ARPA Re: Type Specifier: (OR (FUNCTION ...) ...)
C01447 00418 ∂22-Apr-86 0754 DLW@SCRC-STONY-BROOK.ARPA What is a compiler (vol. 63827) meets what are gensyms.
C01450 00419 ∂22-Apr-86 0949 greek%bach.decnet@hudson.dec.com Proclaiming IGNORE
C01451 00420 ∂22-Apr-86 0949 greek%bach.decnet@hudson.dec.com A New &IGNORE keyword
C01453 00421 ∂22-Apr-86 0949 greek%bach.decnet@hudson.dec.com Ignoring bound variables.
C01454 00422 ∂22-Apr-86 1258 Moon@SCRC-STONY-BROOK.ARPA What is a compiler (vol. 63827) meets what are gensyms.
C01457 00423 ∂22-Apr-86 1343 JAR@MC.LCS.MIT.EDU What is a compiler (vol. 63827) meets what are gensyms.
C01463 00424 ∂22-Apr-86 1406 Gregor.pa@Xerox.COM Re: What is a compiler (vol. 63827) meets what are gensyms.
C01465 00425 ∂23-Apr-86 1513 snyder%hplsny@hplabs.ARPA with-output-to-string
C01467 00426 ∂23-Apr-86 1847 RAM@C.CS.CMU.EDU with-output-to-string
C01469 00427 ∂23-Apr-86 1932 Moon@SCRC-STONY-BROOK.ARPA with-output-to-string
C01471 00428 ∂25-Apr-86 1015 gls@THINK-AQUINAS.ARPA What is a compiler (vol. 63827) meets what are gensyms.
C01473 00429 ∂25-Apr-86 2147 franz!fimass!jkf@kim.berkeley.edu :allow-other-keys
C01476 00430 ∂26-Apr-86 0530 nttlab!umemura@su-shasta.arpa SOFTWARE-TYPE & SOFTWARE-VERSION
C01478 00431 ∂26-Apr-86 1030 pyramid!bein@SUN.COM funcall
C01481 00432 ∂26-Apr-86 1232 FAHLMAN@C.CS.CMU.EDU SOFTWARE-TYPE & SOFTWARE-VERSION
C01485 00433 ∂26-Apr-86 1239 RAM@C.CS.CMU.EDU funcall
C01488 00434 ∂26-Apr-86 1245 FAHLMAN@C.CS.CMU.EDU :allow-other-keys
C01490 00435 ∂26-Apr-86 1823 Pavel.pa@Xerox.COM macro-let and *macroexpand-hook*
C01492 00436 ∂26-Apr-86 1833 Pavel.pa@Xerox.COM macro-let and *macroexpand-hook*
C01494 00437 ∂27-Apr-86 1152 RAM@C.CS.CMU.EDU macro-let and *macroexpand-hook*
C01496 00438 ∂27-Apr-86 1544 KMP@SCRC-STONY-BROOK.ARPA SOFTWARE-TYPE, SOFTWARE-VERSION, ...
C01506 00439 ∂28-Apr-86 0745 greek%bach.decnet@hudson.dec.com Environment Query Functions.
C01508 00440 ∂28-Apr-86 0901 snyder%hplsny@hplabs.ARPA Re: with-output-to-string
C01510 00441 ∂28-Apr-86 1426 lab@rochester.arpa Readtables
C01514 00442 ∂28-Apr-86 1703 GJC@MC.LCS.MIT.EDU Readtables
C01516 00443 ∂28-Apr-86 1838 lab@rochester.arpa Readtables
C01518 00444 ∂29-Apr-86 2139 RPG add to mailing list
C01520 00445 ∂30-Apr-86 0512 somewhere!yuasa@kurims.kurims.kyoto-u.junet
C01524 00446 ∂30-Apr-86 0603 DCP@SAPSUCKER.SCRC.Symbolics.COM Readtables
C01533 00447 ∂30-Apr-86 0726 NGALL@G.BBN.COM Re: FUNCTION and MACROLET
C01537 00448 ∂30-Apr-86 0927 lab@rochester.arpa Readtables
C01543 00449 ∂30-Apr-86 1025 DCP@SAPSUCKER.SCRC.Symbolics.COM Readtables
C01548 00450 ∂30-Apr-86 1127 lab@rochester.arpa Readtables
C01554 00451 ∂30-Apr-86 1154 LOOSEMORE@UTAH-20.ARPA editing a function definition
C01556 00452 ∂30-Apr-86 1159 DCP@SAPSUCKER.SCRC.Symbolics.COM Readtables
C01558 00453 ∂30-Apr-86 1342 DD60@A.CS.CMU.EDU readtables & packages
C01560 00454 ∂30-Apr-86 1444 RAM@C.CS.CMU.EDU FUNCTION and MACROLET
C01563 00455 ∂30-Apr-86 1553 NGALL@G.BBN.COM Re: FUNCTION and MACROLET
C01567 00456 ∂30-Apr-86 2006 FAHLMAN@C.CS.CMU.EDU editing a function definition
C01571 00457 ∂01-May-86 0108 @MIT-REAGAN.ARPA:cfry@OZ.AI.MIT.EDU Environment Query Functions.
C01576 00458 ∂01-May-86 0540 RAM@C.CS.CMU.EDU FUNCTION and MACROLET
C01579 00459 ∂01-May-86 0653 greek%bartok.decnet@hudson.dec.com Environment Query Functions.
C01581 00460 ∂01-May-86 0746 DLW@SAPSUCKER.SCRC.Symbolics.COM editing a function definition
C01584 00461 ∂01-May-86 1716 RAM@C.CS.CMU.EDU Does defmacro need a lexicality barrier?
C01586 00462 ∂01-May-86 1624 Pavel.pa@Xerox.COM Does defmacro need a lexicality barrier?
C01591 00463 ∂01-May-86 1831 Miller.pa@Xerox.COM Re: Does defmacro need a lexicality barrier?
C01593 00464 ∂01-May-86 2145 KMP@SCRC-STONY-BROOK.ARPA Problems with packages
C01600 00465 ∂02-May-86 0440 GJC@MC.LCS.MIT.EDU Problems with packages: work arounds.
C01602 00466 ∂02-May-86 0528 somewhere!yuasa@kurims.kurims.kyoto-u.junet
C01606 00467 ∂02-May-86 0716 RAM@C.CS.CMU.EDU Problems with packages
C01611 00468 ∂02-May-86 0756 FAHLMAN@C.CS.CMU.EDU
C01614 00469 ∂02-May-86 0808 NGALL@G.BBN.COM FUNCTION and MACROLET
C01619 00470 ∂02-May-86 1237 KMP@SCRC-STONY-BROOK.ARPA Problems with packages
C01631 00471 ∂02-May-86 1603 Hornig@SCRC-STONY-BROOK.ARPA Environment Query Functions.
C01634 00472 ∂02-May-86 1630 edsel!sunvalleymall!eb@su-navajo.arpa Lexical references in DEFMACRO
C01640 00473 ∂03-May-86 0710 RAM@C.CS.CMU.EDU Lexical references in DEFMACRO
C01647 00474 ∂03-May-86 1933 Larry←Masinter.PARC@Xerox.COM Re: MACROLET & FUNCTION
C01649 00475 ∂05-May-86 1555 JVC@SU-SCORE.ARPA loop where?
C01651 00476 ∂05-May-86 1601 Gregor.pa@Xerox.COM Re: Lexical references in DEFMACRO
C01653 00477 ∂05-May-86 1706 Moon@SAPSUCKER.SCRC.Symbolics.COM Re: Lexical references in DEFMACRO
C01656 00478 ∂05-May-86 2159 sridhar%tekecs%tektronix.csnet@CSNET-RELAY.ARPA Help in writing infix macro in CL.
C01658 00479 ∂05-May-86 2232 MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA A proposal
C01666 00480 ∂06-May-86 0555 FAHLMAN@C.CS.CMU.EDU Help in writing infix macro in CL.
C01668 00481 ∂06-May-86 0658 DLW@SAPSUCKER.SCRC.Symbolics.COM Why we should not try to add programming environments to the Common Lisp standard
C01673 00482 ∂06-May-86 0709 DCP@SAPSUCKER.SCRC.Symbolics.COM Re: Lexical references in DEFMACRO
C01677 00483 ∂06-May-86 0713 DCP@SAPSUCKER.SCRC.Symbolics.COM Help in writing infix macro in CL.
C01680 00484 ∂06-May-86 0716 NGALL@G.BBN.COM Re: Help in writing infix macro in CL.
C01683 00485 ∂06-May-86 0741 kempf%hplabsc@hplabs.ARPA Re: A proposal
C01686 00486 ∂06-May-86 1049 Gregor.pa@Xerox.COM Re: Lexical references in DEFMACRO
C01688 00487 ∂06-May-86 1104 MATHIS@USC-ISIF.ARPA X3J13 Approval
C01690 00488 ∂06-May-86 1202 Moon@SAPSUCKER.SCRC.Symbolics.COM Re: Lexical references in DEFMACRO
C01693 00489 ∂06-May-86 1755 GSB@MC.LCS.MIT.EDU loop where?
C01695 00490 ∂06-May-86 2341 RAM@C.CS.CMU.EDU Re: Lexical references in DEFMACRO
C01698 00491 ∂07-May-86 0429 GJC@MC.LCS.MIT.EDU infix madness
C01700 00492 ∂07-May-86 1355 Bobrow.pa@Xerox.COM Re: A proposal
C01702 00493 ∂07-May-86 1741 KMP@SCRC-STONY-BROOK.ARPA [JAR@MC.LCS.MIT.EDU: Problems with packages]
C01705 00494 ∂09-May-86 0928 DCP@SAPSUCKER.SCRC.Symbolics.COM format ~nC
C01707 00495 ∂09-May-86 1137 robbins%bach.decnet@hudson.dec.com RE: format ~nC
C01709 00496 ∂10-May-86 0928 tansei!a37078%utokyo-relay.csnet@CSNET-RELAY.ARPA The first note on kanji, sent to junet site in Jan 1986 and some reactions in japan
C01714 00497 ∂10-May-86 1954 RAM@C.CS.CMU.EDU New type specifier?
C01716 00498 ∂11-May-86 1356 RWK@SAPSUCKER.SCRC.Symbolics.COM The first note on kanji, sent to junet site in Jan 1986 and some reactions in japan
C01729 00499 ∂11-May-86 1606 KMP@SCRC-STONY-BROOK.ARPA New type specifier?
C01734 00500 ∂11-May-86 1805 RAM@C.CS.CMU.EDU New type specifier?
C01737 00501 ∂11-May-86 1838 RAM@C.CS.CMU.EDU New type specifier?
C01739 00502 ∂12-May-86 0621 KMP@SCRC-STONY-BROOK.ARPA Void
C01745 00503 ∂12-May-86 1100 @MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU First Class environments in CL ??
C01748 00504 ∂12-May-86 1127 RAM@C.CS.CMU.EDU Void
C01754 00505 ∂12-May-86 1217 Moon@SAPSUCKER.SCRC.Symbolics.COM First Class environments in CL ??
C01759 00506 ∂12-May-86 1557 NGALL@G.BBN.COM Re: First Class environments in CL ??
C01765 00507 ∂12-May-86 1659 RAM@C.CS.CMU.EDU Void
C01768 00508 ∂12-May-86 1723 Moon@SAPSUCKER.SCRC.Symbolics.COM Re: First Class environments in CL ??
C01771 ENDMK
C⊗;
∂13-Feb-86 0932 liz@brillig.umd.edu Re: loop macro
Received: from BRILLIG.UMD.EDU by SU-AI.ARPA with TCP; 13 Feb 86 09:32:20 PST
Received: by brillig.umd.edu (5.9/4.7)
id AA01858; Thu, 13 Feb 86 12:28:02 EST
Message-Id: <8602131728.AA01858@brillig.umd.edu>
To: jeff%aiva.edinburgh.ac.uk@cs.ucl.ac.uk
Cc: common-lisp@su-ai.ARPA
Subject: Re: loop macro
In-Reply-To: Your message of Wed, 12 Feb 86 14:54:08 GMT.
<Wed Feb 12 14:54:08 1986 @ aiva.edinburgh.ac.uk>
Date: Thu, 13 Feb 86 12:27:59 -0500
From: Liz Allen <liz@brillig.umd.edu>
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@cs.ucl.ac.uk>
Re Maryland loop macro: one thing is still unclear to me:
are the iteration variables always stepped in parallel (a
la DO)? Is there any way to have it done sequentially
(DO*)? One reason for linking words in ZetaLoop is to
distinguish these cases.
Always via DO -- they are init'd in parallel; you can use LET to
bind other variables which may be ref'd. Of course, on the iteration
steps, the variables are updated in sequence. The Maryland macro
always expands to a DO with, possibly, one or more LET's around it.
I don't really remember needing to use a DO* type binding of
iteration variables. I guess I would use a LET to bind some common
value and use it in the init part of the iteration values.
-Liz
∂13-Feb-86 1041 RWK@SCRC-STONY-BROOK.ARPA Re: loop macro
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 13 Feb 86 10:41:03 PST
Received: from CROW.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 416556; Thu 13-Feb-86 13:39:57-EST
Date: Thu, 13 Feb 86 13:36 EST
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
Subject: Re: loop macro
To: common-lisp@SU-AI.ARPA
In-Reply-To: <8602131728.AA01858@brillig.umd.edu>
Supersedes: <860213133159.1.RWK@CROW.SCRC.Symbolics.COM>,
<860213133625.2.RWK@CROW.SCRC.Symbolics.COM>
Message-ID: <860213133639.3.RWK@CROW.SCRC.Symbolics.COM>
Date: Thu, 13 Feb 86 12:27:59 -0500
From: Liz Allen <liz@brillig.umd.edu>
I don't really remember needing to use a DO* type binding of
iteration variables. I guess I would use a LET to bind some common
value and use it in the init part of the iteration values.
I use the DO* type of binding far more often than not.
And it isn't an issue for the init part of the iteration,
it's for the stepping.
I think you've kept the part people like least about
LOOP (the keywords) and thrown out one of the parts
people like the most.
∂13-Feb-86 1308 JAR@MC.LCS.MIT.EDU loop
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 13 Feb 86 13:08:01 PST
Date: Thu, 13 Feb 86 16:09:39 EST
From: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
Subject: loop
To: common-lisp@SU-AI.ARPA
Message-ID: <[MC.LCS.MIT.EDU].817522.860213.JAR>
Time to start a CL-LOOP mailing list.
∂13-Feb-86 1313 FAHLMAN@C.CS.CMU.EDU loop
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 13 Feb 86 13:13:01 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 13 Feb 86 16:14:37-EST
Date: Thu, 13 Feb 1986 16:14 EST
Message-ID: <FAHLMAN.12183112282.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
Cc: common-lisp@SU-AI.ARPA
Subject: loop
In-reply-to: Msg of 13 Feb 1986 16:09-EST from Jonathan A Rees <JAR at MC.LCS.MIT.EDU>
Yeah, we had one called CL-ITERATION, I think, but I tried mailing to
that and it didn't work. Maybe something has been archived?
-- Scott
∂13-Feb-86 1323 Gregor.pa@Xerox.COM load-time-eval
Received: from XEROX.COM by SU-AI.ARPA with TCP; 13 Feb 86 13:23:03 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 13 FEB 86 13:23:05 PST
Date: 13 Feb 86 13:23 PST
From: Gregor.pa@Xerox.COM
Subject: load-time-eval
To: Common-Lisp@SU-AI.ARPA
cc: Gregor.pa@Xerox.COM
Message-ID: <860213-132305-1680@Xerox>
I think someone has mentioned this before, but Common Lisp needs a
load-time-eval or deferred-constant facility.
load-time-eval (form) [macro]
When evaluated (by the evaluator) simply evaluates form and returns its
result.
When a use of load-time-eval is compiled (by compile-file) arranges for
form to be evaluated at load-time. The call to load-time-eval when
evaluated will then return the result of having evaulated the form
When compiled to core (by compile-file) simply evaluates form at compile
time and arranges for the call to load-time-eval to return the result of
evaluting form.
It seems like it should be easy for implementors to implement this using
the mechanism they already have for #,.
Or we could have a deferred constant facility like the one in Interlisp.
Or we could have both.
We need something though, because the fact that you can't use #, in a
macro and have it do "what you want" makes #, of limited usefulness.
∂13-Feb-86 1342 FAHLMAN@C.CS.CMU.EDU load-time-eval
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 13 Feb 86 13:42:09 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 13 Feb 86 16:43:36-EST
Date: Thu, 13 Feb 1986 16:43 EST
Message-ID: <FAHLMAN.12183117557.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Gregor.pa@XEROX.COM
Cc: Common-Lisp@SU-AI.ARPA
Subject: load-time-eval
In-reply-to: Msg of 13 Feb 1986 16:23-EST from Gregor.pa at Xerox.COM
I agree that we should make Load-time-eval available to users, since
everyone has it internally and it is useful in certain kinds of code.
I don't remember what Interlisp deferred constants do. Can you
elaborate?
-- Scott
∂13-Feb-86 1433 NGALL@G.BBN.COM Re: load-time-eval
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 13 Feb 86 14:32:51 PST
Date: 13 Feb 1986 17:30-EST
Sender: NGALL@G.BBN.COM
Subject: Re: load-time-eval
From: NGALL@G.BBN.COM
To: Gregor.pa@XEROX.COM
Cc: Common-Lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]13-Feb-86 17:30:37.NGALL>
In-Reply-To: <860213-132305-1680@Xerox>
Date: 13 Feb 86 13:23 PST
From: Gregor.pa@Xerox.COM
To: Common-Lisp@SU-AI.ARPA
Subject: load-time-eval
Message-ID: <860213-132305-1680@Xerox>
I think someone has mentioned this before, but Common Lisp needs a
load-time-eval or deferred-constant facility.
load-time-eval (form) [macro]
When evaluated (by the evaluator) simply evaluates form and returns its
result.
When a use of load-time-eval is compiled (by compile-file) arranges for
form to be evaluated at load-time. The call to load-time-eval when
evaluated will then return the result of having evaulated the form
When compiled to core (by compile-file) simply evaluates form at compile
time and arranges for the call to load-time-eval to return the result of
evaluting form.
What is the meaning of the phrase "When [a use of LOAD-TIME-EVAL] is
compiled to core (by COMPILE-FILE)..." and how does it differ/relate
to the meaning of the phrase "When a use of LOAD-TIME-EVAL is compiled
(by COMPILE-FILE)"? They sound the same to me.
It seems like it should be easy for implementors to implement this using
the mechanism they already have for #,.
Or we could have a deferred constant facility like the one in Interlisp.
Or we could have both.
We need something though, because the fact that you can't use #, in a
macro and have it do "what you want" makes #, of limited usefulness.
How does LOAD-TIME-EVAL relate to #,? Could you give an example? Sorry to be so dense, but I didn't see the prev. disc. on this.
-- Nick
∂13-Feb-86 1514 Gregor.pa@Xerox.COM Re: load-time-eval
Received: from XEROX.COM by SU-AI.ARPA with TCP; 13 Feb 86 15:13:31 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 13 FEB 86 15:09:24 PST
Date: 13 Feb 86 15:09 PST
From: Gregor.pa@Xerox.COM
Subject: Re: load-time-eval
In-reply-to: NGALL@G.BBN.COM's message of 13 Feb 86 17:30 EST
To: NGALL@G.BBN.COM
cc: Gregor.pa@Xerox.COM, Common-Lisp@SU-AI.ARPA
Message-ID: <860213-150925-1811@Xerox>
What is the meaning of the phrase "When [a use of LOAD-TIME-EVAL] is
compiled to core (by COMPILE-FILE)..." and how does it
differ/relate
to the meaning of the phrase "When a use of LOAD-TIME-EVAL is
compiled
(by COMPILE-FILE)"? They sound the same to me.
I guess there is a typo in my message. I should have said "compiled to
core by COMPILE".
load-time-eval is different than #, because you can use it in a macro
and have part of the macroexpansion evaluated at load-time.
Given:
(defmacro my-macro ()
`(my-macro-run-time-function
(load-time-eval
<form which evaluates to object only known at load time>)))
This defun:
(defun foo ()
(my-macro))
is equivalent to:
(defun foo ()
(my-macro-run-time-function
'#,<form which evaluates to object only known at load time>))
∂13-Feb-86 1744 RPG CL-ITERATION
To: common-lisp@SU-AI.ARPA
... still exists.
-rpg-
∂14-Feb-86 0938 LOOSEMORE@UTAH-20.ARPA "include" revisited
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 14 Feb 86 09:38:32 PST
Date: Fri 14 Feb 86 10:37:50-MST
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: "include" revisited
To: common-lisp@SU-AI.ARPA
Message-ID: <12183334972.21.LOOSEMORE@UTAH-20.ARPA>
Some time ago I posted a message to this mailing list concerning the lack of
an "include" or file indirection construct in CL. (The primary motivation
for having such a construct being the lack of any other way to compile
several source files into a single binary file.) It was pointed out that
this could be written as a macro (which reads in the entire contents of the
include'd file and returns it inside a PROGN), and that was the end of the
discussion.
Just now, however, I happened to come across the implementation note on
p.182 in CLtL, which states that it's wrong for a compiler to read in the
entire file before processing any of the forms because of the presence of
multiple packages. So, "include" can't be implemented correctly in this
way either. Rather than introduce a special form for "include", how about
extending the syntax of compile-file to accept either a single input-pathname
or a list of pathnames?
-Sandra
-------
∂14-Feb-86 1018 LOOSEMORE@UTAH-20.ARPA package system error handling
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 14 Feb 86 10:18:11 PST
Date: Fri 14 Feb 86 11:17:34-MST
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: package system error handling
To: common-lisp@SU-AI.ARPA
Message-ID: <12183342206.27.LOOSEMORE@UTAH-20.ARPA>
I'm trying to figure out what should happen when the reader sees something
like editor:buffer and there isn't a package called "editor" or an external
symbol in it called "buffer". CLtL indicates that the reader should "signal
a correctable error to ask the user what he really wants to do". This is
all pretty vague -- does this mean that if the user continues from the error
some reasonable default action is used (like creating the package or making
the symbol external), or does it mean that the user is presented with a list
of alternative actions and asked to choose one? How is this handled in
other implementations? Does anybody really care?
-Sandra
-------
∂14-Feb-86 1137 Moon@SCRC-STONY-BROOK.ARPA package system error handling
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 14 Feb 86 11:37:31 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 417617; Fri 14-Feb-86 14:23:05-EST
Date: Fri, 14 Feb 86 14:22 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: package system error handling
To: common-lisp@SU-AI.ARPA
In-Reply-To: <12183342206.27.LOOSEMORE@UTAH-20.ARPA>
Message-ID: <860214142219.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri 14 Feb 86 11:17:34-MST
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
I'm trying to figure out what should happen when the reader sees something
like editor:buffer and there isn't a package called "editor" or an external
symbol in it called "buffer". CLtL indicates that the reader should "signal
a correctable error to ask the user what he really wants to do". This is
all pretty vague -- does this mean that if the user continues from the error
some reasonable default action is used (like creating the package or making
the symbol external), or does it mean that the user is presented with a list
of alternative actions and asked to choose one? How is this handled in
other implementations? Does anybody really care?
I think this depends on the user-interaction style and programming-environment
conventions of each particular implementation. It's not primarily a language
issue.
In our implementation, the response depends on context. In interactive input,
we explain the problem and permit the user to edit the input to make it correct.
When reading from a non-interactive source, such as a file, we go into the debugger,
allowing suitable recovery choices. For example, reading editor:buffer when only
editor::buffer exists offers to assume a double colon and also offers to call EXPORT.
Other implementations might want to do something different.
In the future, when Common Lisp is extended with error-handling machinery, we
may want to define how these are errors are signalled and allow programmed recovery.
∂14-Feb-86 1143 BSG@SCRC-STONY-BROOK.ARPA Re: loop macro
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 14 Feb 86 11:43:37 PST
Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 417632; Fri 14-Feb-86 14:34:26-EST
Date: Fri, 14 Feb 86 14:43 EST
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Subject: Re: loop macro
To: Soley@MIT-MC.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <860205174634.3.SOLEY@MIT-CHERRY.ARPA>
Message-ID: <860214144330.7.BSG@CONCORD.SCRC.Symbolics.COM>
Date: Wed, 5 Feb 86 17:46 EST
From: Soley@MIT-MC.ARPA
Date: 4 Feb 86 15:50 PST
From: Gregor.pa@Xerox.COM
Subject: Re: loop macro
In-reply-to: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>'s message
of Tue, 4 Feb 86 16:38 EST
To: BSG@SCRC-STONY-BROOK.ARPA
cc: Fahlman@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA
Message-ID: <860204-155111-2418@Xerox>
I think I prefer "lispy" iteration macros. Here is an example of what I
mean by a lispy iteration macro:
;; Return a list of the items in list-of-items
;; which pass the test TEST.
(iterate ((item in list-of-items))
(when (test item)
(collect item)))
Parens do not a Lisp code make. This particular example, for instance,
isn't any "lispier" than the equivalent LOOP construction; the
expression "(collect item)" is CERTAINLY not a call to some new function
COLLECT, is it?
Don't laugh, Richard. Suppose ITERATE fletted the name COLLECT.....
That could be a very reasonable implementation.
∂14-Feb-86 1607 hpfclp!hpfcdcm!dcm@hplabs.ARPA FUNCTION type specifier
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 14 Feb 86 16:06:59 PST
Received: by hplabs.ARPA ; Fri, 14 Feb 86 16:06:37 pst
Date: Fri, 14 Feb 86 16:06:37 pst
From: hpfclp!hpfcdcm!dcm@hplabs.ARPA
To: common-lisp@SU-AI
Subject: FUNCTION type specifier
In the description of typep, the following statement seems to need
clarification.
"The type may be any of the type specifiers mentioned in chapter 4
expcept that it may not be or contain a type specifier list whose
first element is FUNCTION or VALUES."
What is the correct interpretation of this statment or its intention?
I am not an expert on English (is anyone?), but I believe this means
that type may not be FUNCTION or VALUES or a type specifier list whose
first element is FUNCTION or VALUES. Based on this interpretation I would
assume the following examples are not valid.
(typep x 'function)
(typep x '(function (t) t))
(typep x 'values)
(typep x '(values t t t))
I believe the first example is quite useful - it is equivalent to
(typep x '(satisfies functionp))
However the second example may not be easy to handle without requiring
implementations to keep a lot of information around. I assume the
restriction was made to simplify implementation for this reason. Was
it really intended to eliminate the useful form as well? Some (maybe all)
implementations do accept the simple FUNCTION type specifier.
Dave Matthews
Hewlett-Packard Company
dcm%hpfclp@hplabs
∂14-Feb-86 1608 hpfclp!diamant@hplabs.ARPA Re: intern
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 14 Feb 86 16:07:47 PST
Received: by hplabs.ARPA ; Fri, 14 Feb 86 16:07:53 pst
Date: Fri, 14 Feb 86 16:07:53 pst
From: hpfclp!diamant@hplabs.ARPA
To: common-lisp@su-ai.ARPA
Subject: Re: intern
Cc: diamant@hplabs.ARPA
From: hplabs!NGALL@G.BBN.COM
Subject: Re: intern
What I would like to see is the following:
1. Leave the stipulation on page 172 that INTERN fix-up the package
slot of an interned symbol.
It may be better to remove the definition of the verb "intern" on pg. 172
since the verb is not used elsewhere in the chapter. See my comments below.
2. Refer to pg. 172 in the def. of INTERN.
I think it would be a better idea to completely define the functionality of
INTERN in one place (preferably on page 184).
3. Make IMPORT also fix up the package slot.
I agree.
4. In UNITERN, after warning about homeless interned symbols, cf.
IMPORT for fixing things up.
5. Make clear that FIND-SYMBOL has NO SIDE EFFECTS. And point out
that it is the only way of mapping a name to a homeless interned
symbol.
For the reasons described below, I would suggest stating that INTERN also
does not modify already-existing symbols.
How 'bout it?!
This appears O.K. at first, but consider the following example:
(in-package "FOO")
(intern "X")
(export 'x)
(in-package "BAR" :use '("FOO"))
(export 'foo:x)
(unintern 'foo:x (find-package "FOO"))
(in-package "BAZ" :use '("BAR"))
(intern "X")
If we follow the proposed definition of intern, x is now internally available
in BAR, available by inheritance in BAZ, but its package cell is BAZ. Now,
if we (unintern 'bar:x (find-package "BAR")), then the symbol will
disappear even though its home package was not BAR. Alternately, if we
(unuse-package "BAR" (find-package "BAZ")), then bar:x has a home package of
BAZ, but is not available in BAZ. This seems to violate print-read consinstency.
(in-package "FOOBAR")
(eq
(read-from-string (with-output-to-string (*standard-output*) (print 'bar:x)))
'bar:x))
This will return nil, instead of t.
An alternative is to have intern not set the home package, but be functionally
equivalent to:
(defun intern (name &optional (package *package*))
(or (find-symbol name package)
(import (make-symbol name) package))))
This has the unfortunate property of having intern return uninterned symbols
in some cases. See the above example.
It seems that we are back to the original statement you made that IMPORT is
the only function permitted to change the package cell (however, the reasons
are more complicated than first suspected). Would anyone care to comment on
this?
By the way, it may be a good idea to make the shadowing-import explicitly
state the same clarification.
I suspect that the (defun intern ...) I stated above is close to what most
people implemented.
∂15-Feb-86 2050 Miller.pa@Xerox.COM Re: loop macro
Received: from XEROX.COM by SU-AI.ARPA with TCP; 15 Feb 86 20:50:26 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 15 FEB 86 20:49:37 PST
Date: 15 Feb 86 20:49 PST
From: Miller.pa@Xerox.COM
Subject: Re: loop macro
In-reply-to: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>'s message of Thu,
6 Feb 86 20:44 EST
To: DLW@SCRC-QUABBIN.ARPA
cc: gls@aquinas.think.com, common-lisp@SU-AI.ARPA
Message-ID: <860215-204937-3274@Xerox>
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Date: Wed, 5 Feb 86 12:01 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Okay, now here is a different perspective on the LOOP problem. I
will play
devil's advocate here and claim that the main purpose of LOOP is to
duplicate the functionality of the sequence functions.
(1) Your message later goes on to say "This isn't operating on
sequences, so I will render this as a DO loop." This in no way
supports the original thesis! Many simple examples of LOOP don't
operate on sequences:
(loop for x from 3 to 6
do (print x))
I think the best answer for this particular kind of example is the
following from Larry Masinter:
We could enhance the sequence functions using Common Loops if we
define default implementations for them which use only the methods
that all ordered collections must follow, and then include new classes
for Interval. This is the approach used successfully in Smalltalk for
dealing with iteration.
In particular, how about:
(map #'print (interval 3 6))
Admittedly, many of GLS's other DO loops examples may be difficult or
inappropriate to rephrase this way.
∂16-Feb-86 1711 FAHLMAN@C.CS.CMU.EDU intern
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 16 Feb 86 17:11:23 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 16 Feb 86 20:12:33-EST
Date: Sun, 16 Feb 1986 20:12 EST
Message-ID: <FAHLMAN.12183942021.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: hpfclp!diamant@HPLABS.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: intern
In-reply-to: Msg of 14 Feb 1986 19:07-EST from hpfclp!diamant at hplabs.ARPA
The reason I haven't jumped into this INTERN discussion is that this
ground was gone over at great length sometime in the last year (but not
since the Boston meeting), and most of these INTERN problems were
resolved, more or less. But it is very difficult for me to get at the
archives right now, and I haven't had time to go back and review the
finer points of what was decided. (Yes, it is totally unacceptable that
the archives are not available in convenient form. The current plan is
that the ISI support group will solve this problem when and if they ever
get rolling.)
If anyone has this stuff available, it would be very helpful if you
could post a synopsis of the previous intern discussion.
-- Scott
∂16-Feb-86 1717 FAHLMAN@C.CS.CMU.EDU FUNCTION type specifier
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 16 Feb 86 17:17:48 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 16 Feb 86 20:19:01-EST
Date: Sun, 16 Feb 1986 20:18 EST
Message-ID: <FAHLMAN.12183943201.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: hpfclp!hpfcdcm!dcm@HPLABS.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: FUNCTION type specifier
In-reply-to: Msg of 14 Feb 1986 19:06-EST from hpfclp!hpfcdcm!dcm at hplabs.ARPA
In my reading of the specification for TYPEP, I see nothing that would
rule out
(TYPEP X 'FUNCTION)
It does rule out any list-type argument whose car is a list (or any
specifier containing such a list). As you surmised, the intention was
to make it clear that the implementaiton is not required to keep around
the argument-type or return-type information for each function.
-- Scott
∂16-Feb-86 1746 GJC@MC.LCS.MIT.EDU forwared from CommonLoops
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 16 Feb 86 17:44:18 PST
Date: Sun, 16 Feb 86 20:45:55 EST
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Subject: forwared from CommonLoops
To: common-lisp@SU-AI.ARPA
Message-ID: <[MC.LCS.MIT.EDU].820141.860216.GJC>
From: ricks%ic at BERKELEY.EDU (Rick L Spickelmier)
I'm in the process of porting to VAXLISP and I've come across one
thing that I think should be changed. In PCL, #+3600 is used for
3600 specific code. VAXLISP dies on this since 3600 is not a symbol.
The commonlisp book (Steele) also says that #+ items must be symbols.
Comments?
∂16-Feb-86 1753 RAM@C.CS.CMU.EDU intern
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 16 Feb 86 17:53:13 PST
Received: ID <RAM@C.CS.CMU.EDU>; Sun 16 Feb 86 20:54:23-EST
Date: Sun, 16 Feb 1986 20:54 EST
Message-ID: <RAM.12183949643.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Cc: common-lisp@SU-AI.ARPA, hpfclp!diamant@HPLABS.ARPA
Subject: intern
In-reply-to: Msg of 16 Feb 1986 20:12-EST from Scott E. Fahlman <Fahlman>
I believe that it was decided that the correct interpretation of
the manual did not support INTERN setting the package cell.
Contradictory passages were considered to be dated, and inconsistent
with the current notion of package semantics.
It was thought that having INTERN do anything to package cells was
a rather random side-effect, and was better left out since no very
convincing arguments were presented in its favor.
It was pointed out that IMPORT is a function which causes a symbol to
be present in a package. This seems to correspond fairly well to the
notion of intering a symbol. It was decided that having IMPORT home
the symbol made some sense, so the change to IMPORT was put in.
There is a point against INTERN setting the home package which I
believe was not discussed. It is not obvious what package INTERN
should choose at the home. It is a bad idea to set the package
to the one being interned in, since the symbol may not be present in
that package; it may be inherited. If the symbol was subsequently
unexported, it would have a home package yet not be available in that
package. This could be fixed up by choosing some package which the
symbol is present in, but the choice would have to be fairly
arbitrary, since the symbol might be inherited from more than one
package.
Rob
∂16-Feb-86 1853 SOLEY@MC.LCS.MIT.EDU forwared from CommonLoops
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 16 Feb 86 18:53:05 PST
Date: Sun, 16 Feb 86 21:54:41 EST
From: Richard Mark Soley <SOLEY@MC.LCS.MIT.EDU>
Subject: forwared from CommonLoops
To: GJC@MC.LCS.MIT.EDU
cc: common-lisp@SU-AI.ARPA
In-reply-to: Msg of Sun 16 Feb 86 20:45:55 EST from George J. Carrette <GJC at MC.LCS.MIT.EDU>
Message-ID: <[MC.LCS.MIT.EDU].820200.860216.SOLEY>
Date: Sun, 16 Feb 86 20:45:55 EST
From: George J. Carrette <GJC at MC.LCS.MIT.EDU>
To: common-lisp at SU-AI.ARPA
Re: forwared from CommonLoops
From: ricks%ic at BERKELEY.EDU (Rick L Spickelmier)
I'm in the process of porting to VAXLISP and I've come across one
thing that I think should be changed. In PCL, #+3600 is used for
3600 specific code. VAXLISP dies on this since 3600 is not a symbol.
The commonlisp book (Steele) also says that #+ items must be symbols.
It's not so gross to force the #+/#- reader to intern all tokens;
|3600| is a perfectly good symbol. Besides, if we were to allow
numbers in #+/#- expressions, we'd be back to the problem found
soon after the first existence of the 3600, in which a change of
the read base caused #+/#- conditionals to fail . . .
I think it's too restrictive to not allow "fixnum symbols" in #
conditionals.
-- Richard
∂17-Feb-86 0811 shebs%utah-orion@utah-cs.arpa Basic Design Questions
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 17 Feb 86 08:11:24 PST
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA16387; Mon, 17 Feb 86 09:13:17 MST
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA17264; Mon, 17 Feb 86 09:13:14 MST
Date: Mon, 17 Feb 86 09:13:14 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8602171613.AA17264@utah-orion.ARPA>
To: common-lisp@su-ai.arpa
Subject: Basic Design Questions
About a month ago, I had some discussions with Julian Padget concerning
EuLisp vs Common Lisp. One suggestion I found interesting was that the
very lowest level of Eulisp, while lexically scoped, would not necessarily
have lexical closures. In fact, it might be the moral equivalent of
Pascal (yech), in terms of functionality, and in terms of how much
reinvention of the wheel would be necessary to use the subset for real
programs. This doesn't bother me a lot, since people wouldn't use this
subset except for very special purposes (education, and maybe as
machine-independent object code).
The real reason for this posting has to do with the issue of single value
cell vs value cell/function cell. Now I don't want to start a session
with flamethrowers - here are some specific questions:
1. I've always assumed that the double cell arrangement in Common Lisp
was for backwards compatibility. Is this true? Are there any other
strong reasons for retaining the duality? Does anyone believe that
efficiency is an issue?
2. (for diehard Schemers only) The strongest reason I've heard for the
single cell arrangement is simplicity. Semantic "purity" or "rationality"
is frequently claimed, but that's incredibly subjective, so it seems less
strong to me. Are there any other reasons?
3. How hard is it really to embed a double cell Lisp in a single cell one,
taking into account compiler effects, changes to existing user programs,
and so forth? Can it be done without destroying performance?
4. How hard is it to embed a single cell Lisp in a double cell one?
One of the problems with doing this is handling user programs that try
to do things like mentioning "#'" and using a variable called "function"
in the same lexical scope. Are there good ways of handling this without
transforming the program? How about efficiency?
My superficial analysis is that implementing double cell Lisp in single cell
Lisp is easier than the reverse, since one can use the ancient expedient
of the property list, and do tricky things in the compiler. Implementing
single cell behavior in a double cell Lisp seems harder, without completely
replacing the interpreter. I have no idea about relative efficiencies of
these schemes (no pun intended!).
stan
∂17-Feb-86 1039 shebs%utah-orion@utah-cs.arpa Re: Basic Design Questions
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 17 Feb 86 10:33:28 PST
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA18832; Mon, 17 Feb 86 11:35:17 MST
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA18028; Mon, 17 Feb 86 11:35:14 MST
Date: Mon, 17 Feb 86 11:35:14 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8602171835.AA18028@utah-orion.ARPA>
To: RAM@c.cs.cmu.edu
Subject: Re: Basic Design Questions
Cc: common-lisp@su-ai.arpa
The problem of upward funargs is neatly solved by excluding functional
objects from the language. It may be that this is too drastic for the
EuLispers; it was just a suggestion! Making Common Lisp subsets is like
trimming the federal budget; almost everybody favors it, but when anyone
makes specific suggestions, the howls of outrage can be heard all the way
to the moon...
Your comment about macros reminds me of the little hole that a great
many macro setups have: it's called **macroarg** in Spice, and woe to
they who refer to it indiscriminately in user code! Actually, I can't get
upset about anything that discourages macro writing - I've seen whole
systems whose validity hung on the convolutions of a single ill-advised
macro...
stan
∂17-Feb-86 1040 RAM@C.CS.CMU.EDU Basic Design Questions
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 17 Feb 86 10:35:37 PST
Received: ID <RAM@C.CS.CMU.EDU>; Mon 17 Feb 86 13:10:12-EST
Date: Mon, 17 Feb 1986 13:09 EST
Message-ID: <RAM.12184127168.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: shebs%utah-orion@λutah-cs.arpa (Stanley Shebs)λ
Cc: common-lisp@SU-AI.ARPA
Subject: Basic Design Questions
In-reply-to: Msg of 17 Feb 1986 11:13-EST from shebs%utah-orion at utah-cs.arpa (Stanley Shebs)
If you have a lexical Lisp without closures, how do you deal with
upward funargs? Dump core? Pascal gets away without closures by not
having first-class functional values; this doesn't seem to work very
well in Lisp. Alternatively, the compiler could signal an error
whenever it couldn't prove you weren't creating a closure. That would
be even sillier, since the compiler would be doing all the work of
implementing closures without getting any of the benefit. You
certainly wouldn't want warts like these in an "educational subset."
An interesting point in favor of the function/variable split is
that it makes macros work better. Most bindings in programs are
variable bindings, while most global references are function
references. If the program binds something that the macroexpansion
references then the macro won't work. This is because macros aren't
referentially transparent.
If the bindings that a program makes don't intersect with the
functions that the macroexpansion is trying to reference, then the
macro works. If the set of global references is mostly disjoint from
the set of local bindings, then more macros will work the first time.
Separating the functional and normal values tends to have this effect.
Yes this is an ad-hoc kludge, but that's what Lisp is all about. Lisp
is getting things done that we don't yet know how to do right.
Rob
∂17-Feb-86 1040 NGALL@G.BBN.COM Re: intern
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 17 Feb 86 10:35:32 PST
Date: 17 Feb 1986 13:33-EST
Sender: NGALL@G.BBN.COM
Subject: Re: intern
From: NGALL@G.BBN.COM
To: hpfclp!diamant@HPLABS.ARPA
Cc: common-lisp@SU-AI.ARPA, diamant@HPLABS.ARPA
Message-ID: <[G.BBN.COM]17-Feb-86 13:33:11.NGALL>
In-Reply-To: The message of Fri, 14 Feb 86 16:07:53 pst from hpfclp!diamant@hplabs.ARPA
From: hpfclp!diamant@hplabs.ARPA
Subject: Re: intern
From: hplabs!NGALL@G.BBN.COM
Subject: Re: intern
What I would like to see is the following:
1. Leave the stipulation on page 172 that INTERN fix-up the package
slot of an interned symbol.
It may be better to remove the definition of the verb "intern" on pg. 172
since the verb is not used elsewhere in the chapter. See my comments below.
But the verb is used by Common Lispers, and many times incorrectly (e.g., the
current definition of the verb is incorrectly applied to symbols
instead of names). So I would like to see the use of INTERN as a verb
and adjective defined about where it is now.
2. Refer to pg. 172 in the def. of INTERN.
I think it would be a better idea to completely define the functionality of
INTERN in one place (preferably on page 184).
Agreed.
3. Make IMPORT also fix up the package slot.
I agree.
4. In UNITERN, after warning about homeless interned symbols, cf.
IMPORT for fixing things up.
5. Make clear that FIND-SYMBOL has NO SIDE EFFECTS. And point out
that it is the only way of mapping a name to a homeless interned
symbol.
For the reasons described below, I would suggest stating that INTERN also
does not modify already-existing symbols.
Agreed.
This appears O.K. at first, but consider the following example:
(in-package "FOO")
(intern "X")
(export 'x)
(in-package "BAR" :use '("FOO"))
(export 'foo:x)
(unintern 'foo:x (find-package "FOO"))
(in-package "BAZ" :use '("BAR"))
(intern "X")
If we follow the proposed definition of intern, x is now internally available
in BAR, available by inheritance in BAZ, but its package cell is BAZ. Now,
if we (unintern 'bar:x (find-package "BAR")), then the symbol will
disappear even though its home package was not BAR. Alternately, if we
(unuse-package "BAR" (find-package "BAZ")), then bar:x has a home package of
BAZ, but is not available in BAZ. This seems to violate print-read consinstency.
(in-package "FOOBAR")
(eq
(read-from-string (with-output-to-string (*standard-output*) (print 'bar:x)))
'bar:x))
This will return nil, instead of t.
An alternative is to have intern not set the home package, but be functionally
equivalent to:
(defun intern (name &optional (package *package*))
(or (find-symbol name package)
(import (make-symbol name) package))))
This has the unfortunate property of having intern return uninterned symbols
in some cases. See the above example.
And of always importing NIL :-).
It seems that we are back to the original statement you made that IMPORT is
the only function permitted to change the package cell (however, the reasons
are more complicated than first suspected). Would anyone care to comment on
this?
Since UNINTERN is the only other function that is allowed to modify
the package cell, perhaps CLtL should state either that:
1. It is an error to UNINTERN a symbol from its home package if it is
present in some other package; or,
2. An error is signaled in case 1 [I prefer this case.]
Saying (1) would at least warn people that "all bets are off" if they
create an accessible but unowned symbol and would allow
implementations that were concerned about it to signal an error.
Requiring (2) would be a bit more overhead, but since UNINTERN is
rarely used (right?), I think it would be acceptable.
By the way, it may be a good idea to make the shadowing-import explicitly
state the same clarification.
Agreed.
∂17-Feb-86 1045 NGALL@G.BBN.COM Re: intern
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 17 Feb 86 10:45:15 PST
Date: 17 Feb 1986 13:42-EST
Sender: NGALL@G.BBN.COM
Subject: Re: intern
From: NGALL@G.BBN.COM
To: RAM@C.CS.CMU.EDU
Cc: Fahlman@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA
Cc: hpfclp!diamant@HPLABS.ARPA
Message-ID: <[G.BBN.COM]17-Feb-86 13:42:30.NGALL>
In-Reply-To: <RAM.12183949643.BABYL@C.CS.CMU.EDU>
Date: Sun, 16 Feb 1986 20:54 EST
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Subject: intern
In-Reply-To: Msg of 16 Feb 1986 20:12-EST from Scott E. Fahlman <Fahlman>
Message-ID: <RAM.12183949643.BABYL@C.CS.CMU.EDU>
I believe that it was decided that the correct interpretation of
the manual did not support INTERN setting the package cell.
Contradictory passages were considered to be dated, and inconsistent
with the current notion of package semantics.
It was thought that having INTERN do anything to package cells was
a rather random side-effect, and was better left out since no very
convincing arguments were presented in its favor.
It was pointed out that IMPORT is a function which causes a symbol to
be present in a package. This seems to correspond fairly well to the
notion of intering a symbol. It was decided that having IMPORT home
the symbol made some sense, so the change to IMPORT was put in.
There is a point against INTERN setting the home package which I
believe was not discussed. It is not obvious what package INTERN
should choose at the home. It is a bad idea to set the package
to the one being interned in, since the symbol may not be present in
that package; it may be inherited. If the symbol was subsequently
unexported, it would have a home package yet not be available in that
package. This could be fixed up by choosing some package which the
symbol is present in, but the choice would have to be fairly
arbitrary, since the symbol might be inherited from more than one
package.
Rob
--------------------
This is pretty much how I remember the discussion.
-- Nick
∂17-Feb-86 1248 hpfclp!diamant@hplabs.ARPA intern
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 17 Feb 86 12:47:49 PST
Received: by hplabs.ARPA ; Mon, 17 Feb 86 12:47:35 pst
Date: Mon, 17 Feb 86 12:47:35 pst
From: hpfclp!diamant@hplabs.ARPA
To: common-lisp@su-ai.ARPA
Subject: intern
From: Rob MacLachlan <hplabs!RAM@C.CS.CMU.EDU>
...
First of all, I'm satisfied with what was apparently concluded several months
ago. Unfortunately, I wasn't aware of the original discussion until I was
already deeply involved in the current one. As long as the definition of
the verb "intern" is either cleaned up or separated from the function INTERN,
I would be satisfied, especially now that IMPORT has been defined to set
the package cell if necessary.
There is a point against INTERN setting the home package which I
believe was not discussed. It is not obvious what package INTERN
should choose at the home. It is a bad idea to set the package
to the one being interned in, since the symbol may not be present in
that package; it may be inherited. If the symbol was subsequently
unexported, it would have a home package yet not be available in that
package. This could be fixed up by choosing some package which the
symbol is present in, but the choice would have to be fairly
arbitrary, since the symbol might be inherited from more than one
package.
Rob
That is exactly the point I made in my last message. The reason I created
a print-read inconsitency is that I assumed INTERN would set the package cell
to the package in which the symbol was being interned. We agree that this
is a good reason to prevent INTERN from setting the package cell.
From: hplabs!NGALL@G.BBN.COM
Since UNINTERN is the only other function that is allowed to modify
the package cell, perhaps CLtL should state either that:
1. It is an error to UNINTERN a symbol from its home package if it is
present in some other package; or,
2. An error is signaled in case 1 [I prefer this case.]
Saying (1) would at least warn people that "all bets are off" if they
create an accessible but unowned symbol and would allow
implementations that were concerned about it to signal an error.
Requiring (2) would be a bit more overhead, but since UNINTERN is
rarely used (right?), I think it would be acceptable.
I'm not convinced that this is a good idea. What if I want to move symbols
from one package to another, but I want all of the references from any other
location to point to the new place. I just had to do something like this
recently to handle a bootstrap. Because of the nature of packages and macros,
I had a case where I had to compile a system in which code may reference either
old or new locations during the compile. I performed this move by doing
the following:
(defun move-symbol (sym pkg)
(let ((old-pkg (symbol-package sym)))
(unintern sym old-pkg) ; make sym have no home (a bastard?)
(import sym pkg) ; give sym a new home package
(import sym old-pkg)
(export sym pkg) ; assumes sym was originally exported from old-pkg
(export sym old-pkg)))
If you restrict UNINTERN to only work if the symbol has not been imported into
any other package, then move-symbol would probably not work (it is likely
that some of the symbols that were moving had been imported elsewhere). It
seems to me that the operation I performed was perfectly valid (though not
for the weak of heart), and your restriction would limit it. I think the
current approach of warning users that this situation may arise is better
than restricting its use.
John
∂17-Feb-86 1912 FAHLMAN@C.CS.CMU.EDU Basic Design Questions
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 17 Feb 86 19:12:40 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 17 Feb 86 22:14:21-EST
Date: Mon, 17 Feb 1986 22:14 EST
Message-ID: <FAHLMAN.12184226345.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: shebs%utah-orion@λutah-cs.arpa (Stanley Shebs)λ
Cc: common-lisp@SU-AI.ARPA
Subject: Basic Design Questions
In-reply-to: Msg of 17 Feb 1986 11:13-EST from shebs%utah-orion at utah-cs.arpa (Stanley Shebs)
The existence of distinct function and value cells in Common Lisp is in
part because a lot of existing code expects these cells to be distinct,
and that is the sort of expectation that is very hard to undo. In
addition to the question of historical compatibility, many people felt
that using a single name space leads to a lot of extra bugs when some
program rebinds a variable that happens to hold a function that is
called within the scope of the new binding. This bug is much less
likely in a lexically bound lisp than in a dynamic one, but it still is
a danger. Reasonable people can disagree about whether the elegance of
a single namespace is worth the danger of accidentally clobbering
function definitions, but that's what the reasoning was.
-- Scott
∂18-Feb-86 1540 fateman@dali.berkeley.edu value of *
Received: from UCBVAX.BERKELEY.EDU by SU-AI.ARPA with TCP; 18 Feb 86 15:39:43 PST
Received: by ucbvax.berkeley.edu (5.45/1.9)
id AA06539; Tue, 18 Feb 86 15:38:29 PST
Received: by dali.berkeley.edu (5.44/5.16)
id AA16600; Tue, 18 Feb 86 09:22:59 PST
Date: Tue, 18 Feb 86 09:22:59 PST
From: fateman@dali.berkeley.edu (Richard Fateman)
Message-Id: <8602181722.AA16600@dali.berkeley.edu>
To: common-lisp@su-ai.arpa
Subject: value of *
While I can understand the efficiency motivation for the spec on p 325,
I would find it much handier to have "*" refer to multiple-values returns
to the top level. That is,
=> (values 1 2)
1 ;
2
=> (multiple-value-list *)
(1 2)
;;; the behavior now is (1) .
∂18-Feb-86 1656 MOON@SCRC-STONY-BROOK.ARPA value of *
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 18 Feb 86 16:56:33 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 419926; Tue 18-Feb-86 19:54:51-EST
Date: Tue, 18 Feb 86 19:54 EST
From: <MOON@SCRC-QUABBIN.ARPA>
Subject: value of *
To: Richard Fateman <fateman@dali.berkeley.edu>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8602181722.AA16600@dali.berkeley.edu>
Message-ID: <"860218195413.2.MOON@QUABBIN"@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 18 Feb 86 09:22:59 PST
From: fateman@dali.berkeley.edu (Richard Fateman)
While I can understand the efficiency motivation for the spec on p 325,
I would find it much handier to have "*" refer to multiple-values returns
to the top level. That is,
=> (values 1 2)
1 ;
2
=> (multiple-value-list *)
(1 2)
;;; the behavior now is (1) .
Read the rest of the page.
∂18-Feb-86 1657 FAHLMAN@C.CS.CMU.EDU value of *
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 18 Feb 86 16:57:51 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 18 Feb 86 19:58:59-EST
Date: Tue, 18 Feb 1986 19:58 EST
Message-ID: <FAHLMAN.12184463845.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: fateman@λdali.berkeley.edu (Richard Fateman)λ
Cc: common-lisp@SU-AI.ARPA
Subject: value of *
In-reply-to: Msg of 18 Feb 1986 12:22-EST from fateman at dali.berkeley.edu (Richard Fateman)
The variable "/" already has a list of the multiple values, if that's
what you want. Is there some need that this doesn't satisfy?
-- Scott
∂18-Feb-86 1940 GJC@MC.LCS.MIT.EDU Basic Design Questions: function cells
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 18 Feb 86 19:40:05 PST
Date: Tue, 18 Feb 86 22:40:41 EST
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Subject: Basic Design Questions: function cells
To: Fahlman@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA
In-reply-to: Msg of Mon 17 Feb 1986 22:14 EST from Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
Message-ID: <[MC.LCS.MIT.EDU].822188.860218.GJC>
You forgot that people have made various efficiency-based
arguments for function cells. These arguments may be found in
the archives. (I cannot understand them so I wont try to explain it).
Having a function cell also gives the language designer another way to
add more inconsistency to the language, in the way of breaking down
possible analogies, for example LET=>SETQ as FLET=>{nothing-in-CL}.
Also, if in the form (<a> <b> <c>) all of <a> <b> and <c> were
evaluated in the same namespace, and if you said "left-to-right"
evaluation order is preserved then users would imply that to mean
evaluate <a> then <b> then <c>. However, if <a> is evaluated
differently then it might not bother anyone than in some CL
implementations the order of evaluation is <b> <c> <a>, and in some it
is <a> <b> <c>.
-gjc
{You have to know the rules before you can break them.}
∂19-Feb-86 0709 NGALL@G.BBN.COM Re: intern
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 19 Feb 86 07:09:06 PST
Date: 19 Feb 1986 10:05-EST
Sender: NGALL@G.BBN.COM
Subject: Re: intern
From: NGALL@G.BBN.COM
To: hpfclp!diamant@HPLABS.ARPA
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]19-Feb-86 10:05:02.NGALL>
In-Reply-To: The message of Mon, 17 Feb 86 12:47:35 pst from hpfclp!diamant@hplabs.ARPA
Date: Mon, 17 Feb 86 12:47:35 pst
From: hpfclp!diamant@hplabs.ARPA
To: common-lisp@su-ai.ARPA
Subject: intern
....
Since UNINTERN is the only other function that is allowed to modify
the package cell, perhaps CLtL should state either that:
1. It is an error to UNINTERN a symbol from its home package if it is
present in some other package; or,
2. An error is signaled in case 1 [I prefer this case.]
Saying (1) would at least warn people that "all bets are off" if they
create an accessible but unowned symbol and would allow
implementations that were concerned about it to signal an error.
Requiring (2) would be a bit more overhead, but since UNINTERN is
rarely used (right?), I think it would be acceptable.
I'm not convinced that this is a good idea. What if I want to move symbols
from one package to another, but I want all of the references from any other
location to point to the new place. I just had to do something like this
recently to handle a bootstrap. Because of the nature of packages and macros,
I had a case where I had to compile a system in which code may reference either
old or new locations during the compile. I performed this move by doing
the following:
(defun move-symbol (sym pkg)
(let ((old-pkg (symbol-package sym)))
(unintern sym old-pkg) ; make sym have no home (a bastard?)
(import sym pkg) ; give sym a new home package
(import sym old-pkg)
(export sym pkg) ; assumes sym was originally exported from old-pkg
(export sym old-pkg)))
If you restrict UNINTERN to only work if the symbol has not been imported into
any other package, then move-symbol would probably not work (it is likely
that some of the symbols that were moving had been imported elsewhere). It
seems to me that the operation I performed was perfectly valid (though not
for the weak of heart), and your restriction would limit it. I think the
My restrictiction would disallow your def. of MOVE-SYMBOL, but you
could easily unintern the symbol from all the packages it is present
in (except of course the old home package) (and of course keeping a
list of those packages, and info. as to whether or not the symbol was
external) BEFORE uninterning the symbol from its home package. THEN,
you import it into it's new home package, and import/export it back
into the other packages it was present in. [Note: Your def. of move
symbol did not deal with the problem of using SHADOWING-IMPORT where
necessary, so neither does my alternative.]
Other than changing a symbol's home package, I doubt that my
restriction would ever get in anyone's way.
current approach of warning users that this situation may arise is better
than restricting its use.
I'd rather warn the user when it happens, since that's when they need
the warning. :-)
-- Nick
∂19-Feb-86 0845 Swenson.Multics@CISL-SERVICE-MULTICS.ARPA Re: Basic Design Questions: function cells
Received: from CISL-SERVICE-MULTICS.ARPA by SU-AI.ARPA with TCP; 19 Feb 86 08:44:54 PST
Posted-Date: 19 Feb 86 11:45 EST
Acknowledge-To: "Eric J. Swenson" <Swenson@CISL-SERVICE-MULTICS.ARPA>
Date: Wed, 19 Feb 86 11:24 EST
From: "Eric J. Swenson" <Swenson@CISL-SERVICE-MULTICS.ARPA>
Subject: Re: Basic Design Questions: function cells
To: common-lisp@SU-AI.ARPA
In-Reply-To: Message of 18 Feb 86 22:40 EST from "George J. Carrette"
Message-ID: <860219162459.161471@CISL-SERVICE-MULTICS.ARPA>
I too don't understand the arguments of the efficiency of the function
cell concept, however, from the standpoint of looking at CL as a NEW
language (as opposed to a pot-pouri of all the existing Lisp dialects)
it certainly seems that CL is clutterred with pairs of functions/macros
to deal with functional and non-functional objects and that elegance has
been sacrificed in order to maintain compatibility with the various
older Lisp dialects. I take it that the overriding factor in CL
development has been compatilibity with the major Lisp dialects as
opposed to designing a new language which was more internally consistent
and conceptually elegant?
∂19-Feb-86 1011 LOOSEMORE@UTAH-20.ARPA buffered output and prompting
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 19 Feb 86 10:11:17 PST
Date: Wed 19 Feb 86 11:10:35-MST
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: buffered output and prompting
To: common-lisp@SU-AI.ARPA
Message-ID: <12184651656.29.LOOSEMORE@UTAH-20.ARPA>
I'm having trouble coming up with a portable way for a CL application
program to read with a prompt string. What I would like to do is something
like, but more general than, the y-or-n-p and yes-or-no-p functions:
specify a prompt string and then call read, read-line, or read-char. For a
usual terminal-style interaction, I'd like to have the prompt message
printed out without a newline so the cursor is left at the end of the same
line, and then read. Aside from the fact that writing out the prompt string
directly prevents you from using alternative interaction styles (like a
pop-up dialog box or whatever), it's unclear that you could guarantee
the same behavior, or even reasonable behavior, in all CL implementations.
CLtL implies that buffered i/o is perfectly acceptable, so I assume one would
have to do a (finish-output) after printing the prompt message to ensure that
it really does get printed. However, emptying the internal buffer may mean
that the prompt message shows up with a newline on the end, particularly if
the output stream is organized into records with an implicit newline at
the end of each record. (This is also acceptable, according to page 22.)
Furthermore, the terminal driver provided by the operating system may
include some fancy input editing capabilities that are confused by printing
out random prompt strings; to get the prompt to interact properly with the
editor, you have to pass it to the read function provided by the operating
system. (In fact, all three of these conditions are true under VMS.)
PSL has a variable that holds the current prompt string, and it's used
whenever you read from the terminal. Different PSL implementations use
whatever hooks the OS provides to get the right effect. I also seem to
remember that the NMODE editor does special things with the prompt string
that are more appropriate for its style of interaction. The point is, the
same code will produce reasonable behavior in all situations. How can I
get similar portability in CL code? Do we need to define additional
functions (or additional arguments to existing functions) to support user
interaction?
-Sandra
-------
∂19-Feb-86 1049 nelson%bizet.decnet@hudson.dec.com prompting
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 19 Feb 86 10:48:10 PST
Date: 0 0 00:00:00 EST
From: "BIZET::NELSON" <nelson%bizet.decnet@hudson.dec.com>
Subject: prompting
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BIZET::NELSON" <nelson%bizet.decnet@hudson.dec.com>
Our users have requested a "read-with-prompt" function for IO streams.
Beryl
------
∂19-Feb-86 1113 MOON@SCRC-YUKON.ARPA Re: Basic Design Questions: function cells
Received: from SCRC-YUKON.ARPA by SU-AI.ARPA with TCP; 19 Feb 86 11:12:41 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-YUKON.ARPA via CHAOS with CHAOS-MAIL id 200616; Wed 19-Feb-86 14:10:24-EST
Date: Wed, 19 Feb 86 14:10 EST
From: <MOON@SCRC-QUABBIN.ARPA>
Subject: Re: Basic Design Questions: function cells
To: common-lisp@SU-AI.ARPA
In-Reply-To: <860219162459.161471@CISL-SERVICE-MULTICS.ARPA>
Message-ID: <"860219141034.3.MOON@QUABBIN"@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 19 Feb 86 11:24 EST
From: "Eric J. Swenson" <Swenson@CISL-SERVICE-MULTICS.ARPA>
I too don't understand the arguments of the efficiency of the function
cell concept,
I believe these arguments were comparing storing function definitions in
dedicated cells to storing them in property lists. As far as I know no
one has argued that having functions and variables in separate name spaces
leads to a more or less efficient implementation than having them in the
same name space. I could be wrong; people will argue for almost anything.
however, from the standpoint of looking at CL as a NEW
language (as opposed to a pot-pouri of all the existing Lisp dialects)
it certainly seems that CL is clutterred with pairs of functions/macros
to deal with functional and non-functional objects and that elegance has
been sacrificed in order to maintain compatibility with the various
older Lisp dialects. I take it that the overriding factor in CL
development has been compatilibity with the major Lisp dialects as
opposed to designing a new language which was more internally consistent
and conceptually elegant?
That's certainly true. At the same time, it is a matter of opinion
whether having all of the dozens of possible classes of named objects in
the same space, or each in a separate space, is more elegant. The issue
is not only variables and functions. Without going into extensions to
Common Lisp, you can also think about package names, type names, and module
names. There are powerful arguments on both sides of this issue. All
a language designer can do is pick one philosophy and then be consistent
about it.
∂19-Feb-86 1203 snyder@hplsny Re: Basic Design Questions: function cells
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 19 Feb 86 12:03:41 PST
Received: from hplsny by hplabs.ARPA ; Wed, 19 Feb 86 12:03:24 pst
Received: by hplsny ; Wed, 19 Feb 86 12:02:35 pst
From: Alan Snyder <snyder@hplsny>
Message-Id: <8602192002.AA07562@hplsny>
Date: Wednesday, February 19, 1986 12:02:30
Subject: Re: Basic Design Questions: function cells
To: MOON@SCRC-QUABBIN.ARPA
Cc: common-lisp@su-ai.ARPA
In-Reply-To: Your message of 19-Feb-86 14:10:00
X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46
I believe these arguments were comparing storing function definitions in
dedicated cells to storing them in property lists. As far as I know no
one has argued that having functions and variables in separate name spaces
leads to a more or less efficient implementation than having them in the
same name space.
My impression was that having a separate function cell can be more efficient
because it allows function invocation to be compiled into a direct jsr (or
jump) through the function cell, with no explicit check that the function is
defined (undefined functions are represented by a special undefined-function
function). Using the same cell for functions and other variables would
require checking that the cell contains a function before calling it
(otherwise you might transfer control to a random location).
-------
∂19-Feb-86 1239 gls@THINK-AQUINAS.ARPA Function cells
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 19 Feb 86 12:38:27 PST
Received: from katherine by GODOT.THINK.COM via CHAOS; Wed, 19 Feb 86 15:38:49 est
Date: Wed, 19 Feb 86 15:40 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Function cells
To: common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
Message-Id: <860219154017.1.GLS@KATHERINE.THINK.COM>
My memory is that a question arose as to whether, given that function
cells and value cells were to be distinct, they should have identical
binding mechanisms or not. There was no compelling reason to allow
special binding of function names, and the following argument was
advanced against such special bindings: multiprocessing implementations
of Lisp might well prefer to use deep special binding, and it was
undesirable to have to deal with the deep binding mechanism for function
lookups, given that most function-name references, unlike most
variable-name references, occur free. I recall that this was the
deciding argument that eliminated special binding of function names from
Common Lisp, thereby making function names and variable names dissimilar
in their semantics and further discouraging their merging.
I can report that much of the time I am very happy to have the two names
spaces be distinct. I get very unhappy whenever I find myself inventing
functionals (functions that take other functions as arguments or return
other functions as values) for various purposes. For example, I have
found it semantically convenient to do so in Connection Machine Lisp.
In these situations I find the need for interpolated occurrences of
"funcall" and "#'" extremely annoying.
--Guy
∂19-Feb-86 1240 MATHIS@USC-ISIF.ARPA Standardization proposal
Received: from USC-ISIF.ARPA by SU-AI.ARPA with TCP; 19 Feb 86 12:39:20 PST
Date: 19 Feb 1986 12:39-PST
Sender: MATHIS@USC-ISIF.ARPA
Subject: Standardization proposal
From: MATHIS@USC-ISIF.ARPA
To: common-lisp@SU-AI.ARPA
Cc: Mathis@USC-ISIF.ARPA
Message-ID: <[USC-ISIF.ARPA]19-Feb-86 12:39:34.MATHIS>
Today I sent a proposal to X3 for the establishment of a
technical committee for the development of an American National
Standard for Common Lisp. This committee will probably have the
designation X3J13.
Following their normal time-table, the committee will probably be
approved in early summer and the first official meeting will be
in Washington, DC in September 1986. Membership will be open
according to X3 rules (basically attendance, participation, and
payment of fees).
The proposals are available as net mail, but I would rather only
send them to interested people. If you are interested in seeing
the proposals or participating on the X3J13 committee, please
respond and give me your non-arpa-net addresses as well.
Bob Mathis 9712 Ceralene Dr Fairfax, VA 22032-1704 (703)425-5923
∂19-Feb-86 1241 berman@isi-vaxa.ARPA Re: Basic Design Questions: function cells
Received: from ISI-VAXA.ARPA by SU-AI.ARPA with TCP; 19 Feb 86 12:41:30 PST
Received: by isi-vaxa.ARPA (4.12/4.7)
id AA04673; Wed, 19 Feb 86 12:43:16 pst
From: berman@isi-vaxa.ARPA (Richard Berman)
Message-Id: <8602192043.AA04673@isi-vaxa.ARPA>
Date: 19 Feb 1986 1243-PST (Wednesday)
Cc: Alan Snyder <snyder@hplsny.ARPA>
Subject: Re: Basic Design Questions: function cells
To: common-lisp@su-ai.ARPA
I believe these arguments were comparing storing function definitions in
dedicated cells to storing them in property lists. As far as I know no
one has argued that having functions and variables in separate name spaces
leads to a more or less efficient implementation than having them in the
same name space.
My impression was that having a separate function cell can be more efficient
because it allows function invocation to be compiled into a direct jsr (or
jump) through the function cell, with no explicit check that the function is
defined (undefined functions are represented by a special undefined-function
function). Using the same cell for functions and other variables would
require checking that the cell contains a function before calling it
(otherwise you might transfer control to a random location).
-------
The function cell can also hold the lambda expression for an interpreted
function, so you can't do a blind JSR anyway.
RB
∂19-Feb-86 1328 kessler%utah-orion@utah-cs.arpa re: Function Cells
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 19 Feb 86 13:28:01 PST
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA01272; Wed, 19 Feb 86 14:29:59 MST
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA00286; Wed, 19 Feb 86 14:29:56 MST
Date: Wed, 19 Feb 86 14:29:56 MST
From: kessler%utah-orion@utah-cs.arpa (Robert Kessler)
Message-Id: <8602192129.AA00286@utah-orion.ARPA>
To: common-lisp@su-ai.arpa
Subject: re: Function Cells
> The function cell can also hold the lambda expression for an interpreted
> function, so you can't do a blind JSR anyway.
That is not true. One simply stores the lambda expression on the property
list and stores a call to "CompiledCallingInterpreted" compiled function
in the function cell. "CompiledCallingInterpreted" picks up the lambda
expression from the property list and performs normal interpreted evaluation.
PSL also stores a reference to "UndefinedFunction" in newly made symbols
which causes the undefined function processing to be handled. Thus you can
guarentee that the function cell always contains an executable function
address and never need to check.
Bob.
∂19-Feb-86 1429 snyder@hplsny Re: Basic Design Questions: function cells
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 19 Feb 86 14:23:00 PST
Received: from hplsny by hplabs.ARPA ; Wed, 19 Feb 86 14:21:54 pst
Received: by hplsny ; Wed, 19 Feb 86 14:21:05 pst
From: Alan Snyder <snyder@hplsny>
Message-Id: <8602192221.AA07885@hplsny>
Date: Wednesday, February 19, 1986 14:21:00
Subject: Re: Basic Design Questions: function cells
To: berman@isi-vaxa.ARPA
Cc: common-lisp@su-ai.ARPA
In-Reply-To: Your message of 19-Feb-86 12:43:00
X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46
The function cell can also hold the lambda expression for an interpreted
function, so you can't do a blind JSR anyway.
Your assumption that the lambda expression for an interpreted function must be
stored in the function cell is incorrect. PSL used the implementation
technique that I described, with good results.
-------
∂19-Feb-86 1618 Fischer.pa@Xerox.COM Re: transfer control to a random location
Received: from XEROX.COM by SU-AI.ARPA with TCP; 19 Feb 86 15:55:25 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 19 FEB 86 15:43:08 PST
Date: 19 Feb 86 15:42 PST
From: Fischer.pa@Xerox.COM
Subject: Re: transfer control to a random location
In-reply-to: Alan Snyder <snyder@hplsny.ARPA>'s message of Wednesday,
February 19, 1986 12:02:30
To: snyder@hplsny.ARPA
cc: MOON@SCRC-QUABBIN.ARPA, common-lisp@su-ai.ARPA
Message-ID: <860219-154308-3347@Xerox>
Why should Common Lisp worry about this efficiency? It "would be an
error" just like so many other things that can destroy a "fast" Common
Lisp.
Now if you mean this is one small case where the language favors a
conventional machine...
(ron)
∂19-Feb-86 1809 GRISS@HP-HULK Re: Basic Design Questions: function cells
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 19 Feb 86 18:03:37 PST
Received: from HP-HULK by hplabs.ARPA ; Wed, 19 Feb 86 18:02:24 pst
Date: Wed 19 Feb 86 18:00:48-PST
From: Martin <GRISS%HP-HULK@HPLABS>
Subject: Re: Basic Design Questions: function cells
To: berman@isi-vaxa.ARPA
Cc: GRISS%HP-HULK@HPLABS, common-lisp%su-ai@HPLABS
In-Reply-To: Message from "berman@isi-vaxa.ARPA (Richard Berman)" of Wed 19 Feb 86 12:43:00-PST
Return-Path: <@SU-AI.ARPA:berman@isi-vaxa.ARPA>
Received: from hplabs.ARPA by HP-HULK with TCP; Wed 19 Feb 86 13:15:15-PST
Received: from SU-AI.ARPA by hplabs.ARPA ; Wed, 19 Feb 86 13:16:12 pst
Received: from ISI-VAXA.ARPA by SU-AI.ARPA with TCP; 19 Feb 86 12:41:30 PST
Received: by isi-vaxa.ARPA (4.12/4.7)
id AA04673; Wed, 19 Feb 86 12:43:16 pst
From: berman@isi-vaxa.ARPA (Richard Berman)
Message-Id: <8602192043.AA04673@isi-vaxa.ARPA>
Date: 19 Feb 1986 1243-PST (Wednesday)
Cc: Alan Snyder <snyder@hplsny.ARPA>
Subject: Re: Basic Design Questions: function cells
To: common-lisp@su-ai.ARPA
I believe these arguments were comparing storing function definitions in
dedicated cells to storing them in property lists. As far as I know no
one has argued that having functions and variables in separate name spaces
leads to a more or less efficient implementation than having them in the
same name space.
My impression was that having a separate function cell can be more efficient
because it allows function invocation to be compiled into a direct jsr (or
jump) through the function cell, with no explicit check that the function is
defined (undefined functions are represented by a special undefined-function
function). Using the same cell for functions and other variables would
require checking that the cell contains a function before calling it
(otherwise you might transfer control to a random location).
-------
The function cell can also hold the lambda expression for an interpreted
function, so you can't do a blind JSR anyway.
RB
Actually, in our CL implementation, and in PSL before it, there is a
compiled LAMBDA handler function (or "thunk") to which you JSR; it
finds the associated S-expression wherever it is (or reconstructs, or
whatever).
Martin Griss
-------
∂19-Feb-86 2146 pyramid!bein@sri-unix reading floats..
Received: from SRI-UNIX.ARPA by SU-AI.ARPA with TCP; 19 Feb 86 21:45:52 PST
Received: by sri-unix.ARPA (4.12/4.16)
id AA14531; Wed, 19 Feb 86 21:44:44 pst
Received: by pyramid (4.12/3.14)
id AA07331; Wed, 19 Feb 86 21:39:36 pst
Date: 19 Feb 1986 21:36-PST
From: David Bein <pyramid!bein@sri-unix>
Subject: reading floats..
To: common-lisp@SU-AI.ARPA
Cc: bein@sri-unix
Message-Id: <509261796/bein@pyramid>
What do others think the reader for floating point numbers
should do when it calculates a 0 mantissa (for float-digits
equal to 53 this would be 4503599627370496 in terms of
a 53 bit 1.F value) and the smallest exponent which would be 0.0
if given to scale-float? (Assume the digits are non-zero)..
I can see one of the following possibilities:
(1) Could be quiet and produce the smallest possible non-zero
float of the desired type.
(2) Could be quiet and return 0.0.
(3) Could complain about non-zero digits turning into 0.0.
(4) Compute it in a higher format if possible and let it die
when converting that to the desired format.
Note that this question also covers what would be described
as exponent underflow since the mantissa for that would be
too small if we shift the exponent to be in range.
I vote for #3. Note that a proper printer based upon Guy
Steele's "How To Print Floating Point Numbers.." will not
produce digits which fall into this class, so this is only
a question for "virgin" input.
--David
∂20-Feb-86 1002 @MCC.ARPA:ables%mcc-pp@mcc.arpa a note on back messages
Received: from MCC.ARPA by SU-AI.ARPA with TCP; 20 Feb 86 10:02:37 PST
Received: from mcc-pp by MCC.ARPA with TCP; Thu 20 Feb 86 12:01:58-CST
Date: Thu, 20 Feb 86 12:01:15 cst
From: ables%mcc-pp@mcc.arpa (King Ables)
Posted-Date: Thu, 20 Feb 86 12:01:15 cst
Message-Id: <8602201801.AA20728@mcc-pp>
Received: by mcc-pp (4.12/RKA.851124)
id AA20728; Thu, 20 Feb 86 12:01:15 cst
To: clisp%mcc-pp@mcc.arpa
Subject: a note on back messages
Ed or Pat have a line-printer copy of the old messages from CLISP
dating back to November 85 if anyone is interested. It is also
available by logging in on the Dec-20 and typing "bboard clisp".
I will manually forward messages that come to the group until the
necessary aliases are added to the Dec-20 to put us on the list.
They will not be individual messages but in groups (of however many
have come in since the last time I checked). When the "real"
distribution begins, each message will be a separate news article.
∂20-Feb-86 1003 @MCC.ARPA:ables%mcc-pp@mcc.arpa back messages
Received: from MCC.ARPA by SU-AI.ARPA with TCP; 20 Feb 86 10:03:09 PST
Received: from mcc-pp by MCC.ARPA with TCP; Thu 20 Feb 86 12:02:26-CST
Date: Thu, 20 Feb 86 12:01:40 cst
From: ables%mcc-pp@mcc.arpa (King Ables)
Posted-Date: Thu, 20 Feb 86 12:01:40 cst
Message-Id: <8602201801.AA20732@mcc-pp>
Received: by mcc-pp (4.12/RKA.851124)
id AA20732; Thu, 20 Feb 86 12:01:40 cst
To: clisp%mcc-pp@mcc.arpa
Subject: back messages
Wed 19 Feb 86 11:10:35-MST SANDRA <LOOSEMORE@UTAH-20.ARPA>
buffered output and prompting
I'm having trouble coming up with a portable way for a CL application
program to read with a prompt string. What I would like to do is something
like, but more general than, the y-or-n-p and yes-or-no-p functions:
specify a prompt string and then call read, read-line, or read-char. For a
usual terminal-style interaction, I'd like to have the prompt message
printed out without a newline so the cursor is left at the end of the same
line, and then read. Aside from the fact that writing out the prompt string
directly prevents you from using alternative interaction styles (like a
pop-up dialog box or whatever), it's unclear that you could guarantee
the same behavior, or even reasonable behavior, in all CL implementations.
CLtL implies that buffered i/o is perfectly acceptable, so I assume one would
have to do a (finish-output) after printing the prompt message to ensure that
it really does get printed. However, emptying the internal buffer may mean
that the prompt message shows up with a newline on the end, particularly if
the output stream is organized into records with an implicit newline at
the end of each record. (This is also acceptable, according to page 22.)
Furthermore, the terminal driver provided by the operating system may
include some fancy input editing capabilities that are confused by printing
out random prompt strings; to get the prompt to interact properly with the
editor, you have to pass it to the read function provided by the operating
system. (In fact, all three of these conditions are true under VMS.)
PSL has a variable that holds the current prompt string, and it's used
whenever you read from the terminal. Different PSL implementations use
whatever hooks the OS provides to get the right effect. I also seem to
remember that the NMODE editor does special things with the prompt string
that are more appropriate for its style of interaction. The point is, the
same code will produce reasonable behavior in all situations. How can I
get similar portability in CL code? Do we need to define additional
functions (or additional arguments to existing functions) to support user
interaction?
-Sandra
-------
Wed, 19 Feb 86 14:10 EST <MOON@SCRC-QUABBIN.ARPA>
Re: Basic Design Questions: function cells
Date: Wed, 19 Feb 86 11:24 EST
From: "Eric J. Swenson" <Swenson@CISL-SERVICE-MULTICS.ARPA>
I too don't understand the arguments of the efficiency of the function
cell concept,
I believe these arguments were comparing storing function definitions in
dedicated cells to storing them in property lists. As far as I know no
one has argued that having functions and variables in separate name spaces
leads to a more or less efficient implementation than having them in the
same name space. I could be wrong; people will argue for almost anything.
however, from the standpoint of looking at CL as a NEW
language (as opposed to a pot-pouri of all the existing Lisp dialects)
it certainly seems that CL is clutterred with pairs of functions/macros
to deal with functional and non-functional objects and that elegance has
been sacrificed in order to maintain compatibility with the various
older Lisp dialects. I take it that the overriding factor in CL
development has been compatilibity with the major Lisp dialects as
opposed to designing a new language which was more internally consistent
and conceptually elegant?
That's certainly true. At the same time, it is a matter of opinion
whether having all of the dozens of possible classes of named objects in
the same space, or each in a separate space, is more elegant. The issue
is not only variables and functions. Without going into extensions to
Common Lisp, you can also think about package names, type names, and module
names. There are powerful arguments on both sides of this issue. All
a language designer can do is pick one philosophy and then be consistent
about it.
----
Wednesday, February 19, 1986 12:02:30 Alan Snyder <snyder@hplsny>
Re: Basic Design Questions: function cells
I believe these arguments were comparing storing function definitions in
dedicated cells to storing them in property lists. As far as I know no
one has argued that having functions and variables in separate name spaces
leads to a more or less efficient implementation than having them in the
same name space.
My impression was that having a separate function cell can be more efficient
because it allows function invocation to be compiled into a direct jsr (or
jump) through the function cell, with no explicit check that the function is
defined (undefined functions are represented by a special undefined-function
function). Using the same cell for functions and other variables would
require checking that the cell contains a function before calling it
(otherwise you might transfer control to a random location).
-------
19 Feb 1986 1243-PST (Wednesday) berman@isi-vaxa.ARPA (Richard Berman)
Re: Basic Design Questions: function cells
I believe these arguments were comparing storing function definitions in
dedicated cells to storing them in property lists. As far as I know no
one has argued that having functions and variables in separate name spaces
leads to a more or less efficient implementation than having them in the
same name space.
My impression was that having a separate function cell can be more efficient
because it allows function invocation to be compiled into a direct jsr (or
jump) through the function cell, with no explicit check that the function is
defined (undefined functions are represented by a special undefined-function
function). Using the same cell for functions and other variables would
require checking that the cell contains a function before calling it
(otherwise you might transfer control to a random location).
-------
The function cell can also hold the lambda expression for an interpreted
function, so you can't do a blind JSR anyway.
RB
------
19 Feb 1986 12:39-PST MATHIS@USC-ISIF.ARPA Standardization proposal
Today I sent a proposal to X3 for the establishment of a
technical committee for the development of an American National
Standard for Common Lisp. This committee will probably have the
designation X3J13.
Following their normal time-table, the committee will probably be
approved in early summer and the first official meeting will be
in Washington, DC in September 1986. Membership will be open
according to X3 rules (basically attendance, participation, and
payment of fees).
The proposals are available as net mail, but I would rather only
send them to interested people. If you are interested in seeing
the proposals or participating on the X3J13 committee, please
respond and give me your non-arpa-net addresses as well.
Bob Mathis 9712 Ceralene Dr Fairfax, VA 22032-1704 (703)425-5923
------
Wed, 19 Feb 86 15:40 EST Guy Steele <gls@THINK-AQUINAS.ARPA>
Function cells
My memory is that a question arose as to whether, given that function
cells and value cells were to be distinct, they should have identical
binding mechanisms or not. There was no compelling reason to allow
special binding of function names, and the following argument was
advanced against such special bindings: multiprocessing implementations
of Lisp might well prefer to use deep special binding, and it was
undesirable to have to deal with the deep binding mechanism for function
lookups, given that most function-name references, unlike most
variable-name references, occur free. I recall that this was the
deciding argument that eliminated special binding of function names from
Common Lisp, thereby making function names and variable names dissimilar
in their semantics and further discouraging their merging.
I can report that much of the time I am very happy to have the two names
spaces be distinct. I get very unhappy whenever I find myself inventing
functionals (functions that take other functions as arguments or return
other functions as values) for various purposes. For example, I have
found it semantically convenient to do so in Connection Machine Lisp.
In these situations I find the need for interpolated occurrences of
"funcall" and "#'" extremely annoying.
--Guy
------
Wed, 19 Feb 86 14:29:56 MST kessler%utah-orion@utah-cs.arpa (Robert Kessler)
re: Function Cells
> The function cell can also hold the lambda expression for an interpreted
> function, so you can't do a blind JSR anyway.
That is not true. One simply stores the lambda expression on the property
list and stores a call to "CompiledCallingInterpreted" compiled function
in the function cell. "CompiledCallingInterpreted" picks up the lambda
expression from the property list and performs normal interpreted evaluation.
PSL also stores a reference to "UndefinedFunction" in newly made symbols
which causes the undefined function processing to be handled. Thus you can
guarentee that the function cell always contains an executable function
address and never need to check.
Bob.
------
Wednesday, February 19, 1986 14:21:00 Alan Snyder <snyder@hplsny>
Re: Basic Design Questions: function cells
The function cell can also hold the lambda expression for an interpreted
function, so you can't do a blind JSR anyway.
Your assumption that the lambda expression for an interpreted function must be
stored in the function cell is incorrect. PSL used the implementation
technique that I described, with good results.
-------
19 Feb 86 15:42 PST Fischer.pa@Xerox.COM
Re: transfer control to a random location
Why should Common Lisp worry about this efficiency? It "would be an
error" just like so many other things that can destroy a "fast" Common
Lisp.
Now if you mean this is one small case where the language favors a
conventional machine...
(ron)
------
Wed 19 Feb 86 18:00:48-PST Martin <GRISS%HP-HULK@HPLABS>
Re: Basic Design Questions: function cells
Return-Path: <@SU-AI.ARPA:berman@isi-vaxa.ARPA>
Received: from hplabs.ARPA by HP-HULK with TCP; Wed 19 Feb 86 13:15:15-PST
Received: from SU-AI.ARPA by hplabs.ARPA ; Wed, 19 Feb 86 13:16:12 pst
Received: from ISI-VAXA.ARPA by SU-AI.ARPA with TCP; 19 Feb 86 12:41:30 PST
Received: by isi-vaxa.ARPA (4.12/4.7)
id AA04673; Wed, 19 Feb 86 12:43:16 pst
From: berman@isi-vaxa.ARPA (Richard Berman)
Message-Id: <8602192043.AA04673@isi-vaxa.ARPA>
Date: 19 Feb 1986 1243-PST (Wednesday)
Cc: Alan Snyder <snyder@hplsny.ARPA>
Subject: Re: Basic Design Questions: function cells
To: common-lisp@su-ai.ARPA
I believe these arguments were comparing storing function definitions in
dedicated cells to storing them in property lists. As far as I know no
one has argued that having functions and variables in separate name spaces
leads to a more or less efficient implementation than having them in the
same name space.
My impression was that having a separate function cell can be more efficient
because it allows function invocation to be compiled into a direct jsr (or
jump) through the function cell, with no explicit check that the function is
defined (undefined functions are represented by a special undefined-function
function). Using the same cell for functions and other variables would
require checking that the cell contains a function before calling it
(otherwise you might transfer control to a random location).
-------
The function cell can also hold the lambda expression for an interpreted
function, so you can't do a blind JSR anyway.
RB
Actually, in our CL implementation, and in PSL before it, there is a
compiled LAMBDA handler function (or "thunk") to which you JSR; it
finds the associated S-expression wherever it is (or reconstructs, or
whatever).
Martin Griss
-------
19 Feb 1986 21:36-PST David Bein <pyramid!bein@sri-unix> reading floats..
What do others think the reader for floating point numbers
should do when it calculates a 0 mantissa (for float-digits
equal to 53 this would be 4503599627370496 in terms of
a 53 bit 1.F value) and the smallest exponent which would be 0.0
if given to scale-float? (Assume the digits are non-zero)..
I can see one of the following possibilities:
(1) Could be quiet and produce the smallest possible non-zero
float of the desired type.
(2) Could be quiet and return 0.0.
(3) Could complain about non-zero digits turning into 0.0.
(4) Compute it in a higher format if possible and let it die
when converting that to the desired format.
Note that this question also covers what would be described
as exponent underflow since the mantissa for that would be
too small if we shift the exponent to be in range.
I vote for #3. Note that a proper printer based upon Guy
Steele's "How To Print Floating Point Numbers.." will not
produce digits which fall into this class, so this is only
a question for "virgin" input.
--David
∂20-Feb-86 1009 Cassels@SCRC-STONY-BROOK.ARPA reading floats..
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 20 Feb 86 10:09:00 PST
Received: from CUYAHOGA.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 421289; Thu 20-Feb-86 13:05:07-EST
Date: Thu, 20 Feb 86 13:07 EST
From: Robert A. Cassels <Cassels@TENEX.SCRC.Symbolics.COM>
Subject: reading floats..
To: pyramid!bein@SRI-UNIX.ARPA, common-lisp@SU-AI.ARPA
cc: bein@SRI-UNIX.ARPA
In-Reply-To: <509261796/bein@pyramid>
Message-ID: <860220130725.5.CASSELS@CUYAHOGA.SCRC.Symbolics.COM>
Reply-To: Robert A. Cassels <Cassels@SCRC-STONY-BROOK.ARPA>
Date: 19 Feb 1986 21:36-PST
From: David Bein <pyramid!bein@sri-unix>
What do others think the reader for floating point numbers
should do when it calculates a 0 mantissa (for float-digits
equal to 53 this would be 4503599627370496 in terms of
a 53 bit 1.F value) and the smallest exponent which would be 0.0
if given to scale-float? (Assume the digits are non-zero)..
I can see one of the following possibilities:
(1) Could be quiet and produce the smallest possible non-zero
float of the desired type.
(2) Could be quiet and return 0.0.
Either (1) or (2) could be construed as producing "the closest
representable value to the input", but they both seem wrong. Mostly
they are both misleading in that the floating-point result bears little
resemblance to the input.
(3) Could complain about non-zero digits turning into 0.0.
(read-from-string "1e-50") on the Symbolics system currently blows out
with the following error message:
"The number 1E-50 is too small in magnitude for single-precision floating-point format."
Underflow which leaves a denormalized nonzero result is accepted
quietly, since the value is as accurate as possible given the format.
(4) Compute it in a higher format if possible and let it die
when converting that to the desired format.
I don't see how this differs from (3) except that the message the user
gets is more obscure.
Note that this question also covers what would be described
as exponent underflow since the mantissa for that would be
too small if we shift the exponent to be in range.
I vote for #3. Note that a proper printer based upon Guy
Steele's "How To Print Floating Point Numbers.." will not
produce digits which fall into this class, so this is only
a question for "virgin" input.
--David
∂20-Feb-86 1130 @MCC.ARPA:ables%dopey%mcc-pp@mcc.arpa apology
Received: from MCC.ARPA by SU-AI.ARPA with TCP; 20 Feb 86 10:45:52 PST
Received: from mcc-pp by MCC.ARPA with TCP; Thu 20 Feb 86 12:45:09-CST
Posted-Date: Thu, 20 Feb 86 12:43:59 cst
Received: from dopey.MCC.ARPA (dopey) by mcc-pp (4.12/RKA.851124)
id AA20952; Thu, 20 Feb 86 12:44:29 cst
Return-Path: <ables@dopey>
Received: by dopey.MCC.ARPA (2.0/RKA.851124)
id AA05443; Thu, 20 Feb 86 12:43:59 cst
Date: Thu, 20 Feb 86 12:43:59 cst
From: ables%dopey%mcc-pp@mcc.arpa (King Ables)
Message-Id: <8602201843.AA05443@dopey.MCC.ARPA>
To: clisp%mcc-pp@mcc.arpa
Subject: apology
I'm sorry about that big message for those of you who got it (apparently
not EVERYBODY did, thank goodness). I was setting up an alias on my
local machine and got confused for about a minute and a half and that
was all it took. 1000 pardons.
-king
∂20-Feb-86 1315 Swenson.Multics@CISL-SERVICE-MULTICS.ARPA Re: Basic Design Questions: function cells
Received: from CISL-SERVICE-MULTICS.ARPA by SU-AI.ARPA with TCP; 20 Feb 86 13:15:47 PST
Acknowledge-To: "Eric J. Swenson" <Swenson@CISL-SERVICE-MULTICS.ARPA>
Date: Thu, 20 Feb 86 09:46 EST
From: "Eric J. Swenson" <Swenson@CISL-SERVICE-MULTICS.ARPA>
Subject: Re: Basic Design Questions: function cells
To: common-lisp@SU-AI.ARPA
In-Reply-To: Message of 19 Feb 86 18:22 EST from "Fischer.pa at XEROX.COM"
Message-ID: <860220144626.703757@CISL-SERVICE-MULTICS.ARPA>
I've gotten several responses (off the record, it appears since they
were not cc'ed to the common-lisp mailing list) which appear to confirm
my feeling that the two-cell approach in considered to be very ugly and
that this decision must have been based on maintaining compatibility
with existing renditions of Lisp. Another topic, which along similar
veins, appears to hold a consensus is that the multitude of functions
within CL which "only work for global (special) variables and not for
lexically bound variables" and vice-versa is also clumsy in appearance.
Would someone care to explain why it was necessary to devise two-sets of
functions for what (being rather naive, I would think) could have been
combined into one more consistent set?
∂20-Feb-86 1335 FAHLMAN@C.CS.CMU.EDU Basic Design Questions: function cells
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 20 Feb 86 13:29:40 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 20 Feb 86 16:30:18-EST
Date: Thu, 20 Feb 1986 16:30 EST
Message-ID: <FAHLMAN.12184950138.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "Eric J. Swenson" <Swenson@CISL-SERVICE-MULTICS.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Basic Design Questions: function cells
In-reply-to: Msg of 20 Feb 1986 09:46-EST from Eric J. Swenson <Swenson at CISL-SERVICE-MULTICS.ARPA>
I've gotten several responses (off the record, it appears since they
were not cc'ed to the common-lisp mailing list) which appear to confirm
my feeling that the two-cell approach in considered to be very ugly and
that this decision must have been based on maintaining compatibility
with existing renditions of Lisp.
I can't very well argue with your anonymous friends, but in my opinion a
Lisp that stores function definitions in value cells is not as good for
serious programming as one that has two distinct name spaces. As I said
before, this was not just a compatibility issue, at least for some of us.
Another topic, which along similar
veins, appears to hold a consensus is that the multitude of functions
within CL which "only work for global (special) variables and not for
lexically bound variables" and vice-versa is also clumsy in appearance.
Would someone care to explain why it was necessary to devise two-sets of
functions for what (being rather naive, I would think) could have been
combined into one more consistent set?
I have no idea what you're talking about. The only such function I can
think of is PROGV, and that couldn't work for lexical variables.
Gee, I'm sounding almost as grumpy as Moon today...
-- Scott
∂20-Feb-86 1505 DCP@ALLEGHENY.SCRC.Symbolics.COM loop macro
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 20 Feb 86 15:03:18 PST
Received: from NEPONSET.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 423; Thu 20-Feb-86 18:03:22-EST
Date: Thu, 20 Feb 86 18:10 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: loop macro
To: DDYER@SCRC-RIVERSIDE.ARPA,
David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>, common-lisp@SU-AI.ARPA
In-Reply-To: <860207151100.8.DDYER@PURPLE.SWW.Symbolics.COM>
Message-ID: <860220181007.8.DCP@NEPONSET.SCRC.Symbolics.COM>
Date: Fri, 7 Feb 86 15:11 PST
From: DDYER@SCRC-RIVERSIDE.ARPA
Date: Fri, 7 Feb 86 16:11 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Just to set the record straight:
Date: Wed, 5 Feb 86 10:49 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
....
Since I'm getting into details, I should make quite clear that I do not
speak for Moon in the matter of LOOP. Our opinions on this topic
diverge much more than they do on most other topics.
True.
One of my own strong feelings about LOOP that Moon does not share is
that we should get rid of the conditionals.
False. Dan misremembered my position here. Actually, I've believed for
several years that the conditionals in LOOP were the principal mistake in
the current design. If I were doing it over today, I would certainly use
the regular Lisp conditionals, which of course implies changes to the
theory of collection. In the real world, one might consider keeping the
conditionals just for compatibility, but frowning on their use in new code.
The conditionals wouldn't be so bad if there were BEGIN and END markers for
the scope of the body. Adding BEGIN and END as loop keywords would solve
eliminate my objections to the loop conditionals.
Oh, barf. What Moon meant was
(case x
(y (unless (or a b)
(collect xyzzy)))
(z (collect pray))
(otherwise (error "Loser!")))
Just adding block-construct keywords to LOOP is continuing a
beyond-its-time idea.
∂20-Feb-86 1521 DCP@ALLEGHENY.SCRC.Symbolics.COM Function cells
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 20 Feb 86 15:20:51 PST
Received: from NEPONSET.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 424; Thu 20-Feb-86 18:20:57-EST
Date: Thu, 20 Feb 86 18:27 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: Function cells
To: Guy Steele <gls@THINK-AQUINAS.ARPA>, common-lisp@SU-AI.ARPA
In-Reply-To: <860219154017.1.GLS@KATHERINE.THINK.COM>
Message-ID: <860220182741.9.DCP@NEPONSET.SCRC.Symbolics.COM>
Date: Wed, 19 Feb 86 15:40 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
My memory is that a question arose as to whether, given that function
cells and value cells were to be distinct, they should have identical
binding mechanisms or not. There was no compelling reason to allow
special binding of function names, and the following argument was
advanced against such special bindings: multiprocessing implementations
of Lisp might well prefer to use deep special binding, and it was
undesirable to have to deal with the deep binding mechanism for function
lookups, given that most function-name references, unlike most
variable-name references, occur free. I recall that this was the
deciding argument that eliminated special binding of function names from
Common Lisp, thereby making function names and variable names dissimilar
in their semantics and further discouraging their merging.
This is one reason I usually give people who ask me. Consider another
reason: Suppose you allowed deep binding of function cells as 'part of
the language'. What would happen if you bound #'CAR? Doesn't this
effectively force every function to be a true function, even if the
hardware happens to be able to do the operation 10+ times faster than it
takes to do a function call? 'Well, you aren't allowed to (deep) bind
inline functions or functions that compile into instructions.' isn't a
good answer because then we have to agree on what these are, and we
might as well not be a portable language any more.
I can report that much of the time I am very happy to have the two names
spaces be distinct. I get very unhappy whenever I find myself inventing
functionals (functions that take other functions as arguments or return
other functions as values) for various purposes. For example, I have
found it semantically convenient to do so in Connection Machine Lisp.
In these situations I find the need for interpolated occurrences of
"funcall" and "#'" extremely annoying.
I read this last paragraph 3 times and am under the impression you
change your mind on each sentence. I'm really curious what you meant!
∂20-Feb-86 1540 RAM@C.CS.CMU.EDU buffered output and prompting
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 20 Feb 86 15:39:57 PST
Received: ID <RAM@C.CS.CMU.EDU>; Thu 20 Feb 86 18:41:25-EST
Date: Thu, 20 Feb 1986 18:41 EST
Message-ID: <RAM.12184974006.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: buffered output and prompting
In-reply-to: Msg of 19 Feb 1986 13:10-EST from SANDRA <LOOSEMORE at UTAH-20.ARPA>
Date: Wednesday, 19 February 1986 13:10-EST
From: SANDRA <LOOSEMORE at UTAH-20.ARPA>
To: common-lisp at SU-AI.ARPA
Re: buffered output and prompting
I'm having trouble coming up with a portable way for a CL application
program to read with a prompt string. What I would like to do is
something like, but more general than, the y-or-n-p and yes-or-no-p
functions: specify a prompt string and then call read, read-line, or
read-char. For a usual terminal-style interaction, I'd like to have
the prompt message printed out without a newline so the cursor is left
at the end of the same line, and then read.
I believe the solution in TOPS-20 Clisp is the have the terminal
output stream remember the text on the current line. When a read is
done on the stream, this text is passed to the OS prompting call as
the prompt.
I think it is definitely wrong for a FORCE-OUTPUT or FINISH-OUTPUT to
implicitly cause a newline to be written. If it is impossible to
write text without a newline, then these calls are probably no-ops in
your OS.
It isn't true that the Common Lisp I/O precludes the use of a pop-up
window for prompting. All you have to do is define the stream so that
it pops up when you use it. You can do quite a bit with the built-in
stream I/O functions if you are willing to define new kinds of
streams. Common Lisp doesn't specifiy how, but every implementation
should provide some way to define new kinds of streams in Lisp.
Rob
∂20-Feb-86 1653 GJC@MC.LCS.MIT.EDU Function cells
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 20 Feb 86 16:53:11 PST
Date: Thu, 20 Feb 86 19:53:37 EST
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Subject: Function cells
To: gls@AQUINAS.THINK.COM
cc: common-lisp@SU-AI.ARPA
In-reply-to: Msg of Thu 20 Feb 86 18:27 EST from David C. Plummer <DCP at SCRC-QUABBIN.ARPA>
Message-ID: <[MC.LCS.MIT.EDU].825077.860220.GJC>
I lied of course when I said I didnt understand the efficiency arguments
for function cells and their irregular binding semantics. I do understand,
and I think they are hogwash. First, the dynamic binding case might
not really be the most important. It is true that in most code written
*now* a form (<F> <A> <B> <C>) the <F> is 98% evaluated "dynamic"
(or at least it uses a shallow bound global cell, which is not the
same thing really) and the rest of <A> <B> <C> are 90% local or lexical.
But one need not equate global cell with fluid binding. Also one
need not equate multiprocessing fluid binding with DEAP BINDING.
There are easy ways of implementing fluid binding in a multiprocessing
or multiprocessor context without arbitrarily costly table lookups.
(Example, a LMI-LAMBDA 2-processor model running ... to be published...)
The argument DCP mentions that goes like "what if I BIND #'CAR" is
also hogwash. What if I (defun car (x) ...)??? You have the same
problem. A good answer starts off with, "well, when you compiled the function F
you did it in a lexical scope where CAR was bound to a CONSTANT."
Unfortunately to users of common-lisp that isnt a good answer because
common-lisp does not admit of such a *model* of binding and evaluation.
What you want is a model where fluid, local, lexical, all fall out
as the same mechanism with slightly different parameters. I claim that
even MIT freshman get exposed to such models.
∂21-Feb-86 0949 NGALL@G.BBN.COM Re: buffered output and prompting
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 21 Feb 86 09:49:02 PST
Date: 21 Feb 1986 12:46-EST
Sender: NGALL@G.BBN.COM
Subject: Re: buffered output and prompting
From: NGALL@G.BBN.COM
To: RAM@C.CS.CMU.EDU
Cc: LOOSEMORE@UTAH-20.ARPA, common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]21-Feb-86 12:46:01.NGALL>
In-Reply-To: <RAM.12184974006.BABYL@C.CS.CMU.EDU>
Date: Thu, 20 Feb 1986 18:41 EST
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: buffered output and prompting
Date: Wednesday, 19 February 1986 13:10-EST
From: SANDRA <LOOSEMORE at UTAH-20.ARPA>
To: common-lisp at SU-AI.ARPA
Re: buffered output and prompting
I'm having trouble coming up with a portable way for a CL application
program to read with a prompt string. What I would like to do is
something like, but more general than, the y-or-n-p and yes-or-no-p
functions: specify a prompt string and then call read, read-line, or
read-char. For a usual terminal-style interaction, I'd like to have
the prompt message printed out without a newline so the cursor is left
at the end of the same line, and then read.
....
I think it is definitely wrong for a FORCE-OUTPUT or FINISH-OUTPUT to
implicitly cause a newline to be written.
I agree. I don't think pg. 22 implicitly allows FORCE-OUTPUT or
FINISH-OUTPUT to postpend a newline. All pg. 22 says (to me) is that
in some implementations:
1. For output that contains a newline, the output medium may be such
that a newline neither appears as a visible glyph nor causes some
state-change in the carriage-control mechanism or linefeed mechanism
of the output medium (since some output mediums have no such
mechanisms, e.g., a card-punch.) But, the newline must be manifested
in some way, e.g., ending the current card without punching a
line-contiuation indicator (card-punches w/o such a mech. cannot be
used as the output medium for CL, since you couldn't print tokens
conatining more chars. than could be fit onto a single card.)
2. For input that contains a newline, the input medium may be such
that the newline character is not represented as a distinct entity,
e.g. a byte in memory; rather the newline is implicit in the structure
of an input record, e.g., based on the length of the record. But,
there is usually a way to overide such an implicit interpretation, in
order to allow tokens and/or lines which might otherwise be
input with an embedded newline to be input without a newline being
implicitly embedded, e.g., on an input card there is a continuation
indicator that allows lines longer than the number of chars. on a
single card. (note that such an override would be required on card
readers that read cards that could not contain enough chars. for the
longest CL defined symbol (which one is the longest? :-)).
It does not allow printing to or reading from such mediums to throw in
extraneous newlines merely because of peculiarites in nature the
medium, e.g., record-length limits and default interpretations of
distinct records as distinct lines.
For example, FORCE-OUTPUT may cause the current card to be flipped
into the ouput bin, but if it does so, it had better punch the
continuation indicator before doing so.
I think it would be a good idea to clarify FORCE-OUTPUT and
FINISH-OUTPUT so that it is clear that they cannot generate an
implicit newline.
-- Nick
∂21-Feb-86 1127 LOOSEMORE@UTAH-20.ARPA Re: buffered output and prompting
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 21 Feb 86 11:27:10 PST
Date: Fri 21 Feb 86 12:27:13-MST
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: Re: buffered output and prompting
To: NGALL@BBNG.ARPA
cc: RAM@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA
In-Reply-To: <[G.BBN.COM]21-Feb-86 12:46:01.NGALL>
Message-ID: <12185189893.6.LOOSEMORE@UTAH-20.ARPA>
Somehow I think this discussion of whether FORCE-OUTPUT can or can't write
a newline is missing the mark. Leaving aside the issue whether this business
about continuation markers in output records could even be implemented with
the primitives provided by your operating system, restricting a low-level
detail of the implementation like this to support a high-level concept like
reading with a prompt strikes me as being counterproductive. I think that
prompting the user to type something on the keyboard is a common enough
situation that it would be worthwhile to provide a standardized, high-level
interface for doing so. After all, if functions to handle situations that
don't even occur in CL (like get-setf-method-multiple-value!) were deemed
important enough to include in the language specification, it ought to be
worthwhile to provide a high-level hook for a situation that does occur
quite often. Not only would this free the programmer from having to write a
lot of grungy code, but implementors would have maximum freedom to present the
prompt in whatever way is most compatible with the rest of the user interface.
-Sandra
-------
∂21-Feb-86 1239 DCP@ALLEGHENY.SCRC.Symbolics.COM Function cells
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 21 Feb 86 12:39:04 PST
Received: from NEPONSET.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 482; Fri 21-Feb-86 10:20:29-EST
Date: Fri, 21 Feb 86 10:27 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: Function cells
To: George J. Carrette <GJC@MC.LCS.MIT.EDU>, gls@AQUINAS.THINK.COM
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <[MC.LCS.MIT.EDU].825077.860220.GJC>
Message-ID: <860221102725.1.DCP@NEPONSET.SCRC.Symbolics.COM>
If CAR == #'CAR were a constant (because it was microcoded), posit a
machine that 'compiles' function into microcode and assigns instructions
opcodes for them which further compilations then use. [Of course this
creates havoc to programming development.] Now I can't bind function
cells at all unless I happen to use FUNCALL all the time, which might
very well lose some advantages of calling the instruction directly. On
more realistic machines, some 'functions' are constants and some are
not. How can one write portable code that would bind function cells?
MIT students are indeed exposed to these ISSUES which are demonstrated
on CONVENTIONAL hardware (68Ks I believe) that does not run Lisp
natively and therefore bypasses the issues for more Lisp-specific
engines.
∂21-Feb-86 1252 RAM@C.CS.CMU.EDU buffered output and prompting
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 21 Feb 86 12:52:19 PST
Received: ID <RAM@C.CS.CMU.EDU>; Fri 21 Feb 86 15:53:10-EST
Date: Fri, 21 Feb 1986 15:53 EST
Message-ID: <RAM.12185205510.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Cc: common-lisp@SU-AI.ARPA, NGALL@BBNG.ARPA
Subject: buffered output and prompting
In-reply-to: Msg of 21 Feb 1986 14:27-EST from SANDRA <LOOSEMORE at UTAH-20.ARPA>
At one point, there was a prompting function in the Common Lisp
spec. This is another thing that was flushed due to controversiality.
Most people won't dispute that some sort of prompting capability is
useful; the problem is deciding what to provide and how. If you have
a proposal, speak up.
In my message, I was pointing out that it is possible to use OS
prompting features without having a language prompt notion.
Regardless of the desirability of a prompting function, you should
probably support users printing their own prompts.
Rob
∂21-Feb-86 1851 FAHLMAN@C.CS.CMU.EDU buffered output and prompting
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 21 Feb 86 18:51:24 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 21 Feb 86 21:52:23-EST
Date: Fri, 21 Feb 1986 21:52 EST
Message-ID: <FAHLMAN.12185270919.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: NGALL@BBNG.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: buffered output and prompting
In-reply-to: Msg of 21 Feb 1986 12:46-EST from NGALL at G.BBN.COM
I think it is definitely wrong for a FORCE-OUTPUT or FINISH-OUTPUT to
implicitly cause a newline to be written.
I agree. I don't think pg. 22 implicitly allows FORCE-OUTPUT or
FINISH-OUTPUT to postpend a newline.
I agree too. Therefore, I don't think that we need any new machinery in
order to do prompting. You just squeeze out the prompt with a
force-output, and wait for an answer. If some line-oriented systems are
so wedged that they can't type something and then wait for input on the
same line, then they will have to do the best they can and certain
things will be ugly.
-- Scott
∂21-Feb-86 1904 GJC@MC.LCS.MIT.EDU Function cells
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 21 Feb 86 19:03:47 PST
Date: Fri, 21 Feb 86 22:04:25 EST
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Subject: Function cells
To: DCP@SCRC-QUABBIN.ARPA
cc: common-lisp@SU-AI.ARPA, gls@AQUINAS.THINK.COM
In-reply-to: Msg of Fri 21 Feb 86 10:27 EST from David C. Plummer <DCP at SCRC-QUABBIN.ARPA>
Message-ID: <[MC.LCS.MIT.EDU].826494.860221.GJC>
CAR is not a constant because it is microcoded. CAR is (can be legally)
microcoded because it is a constant. Get the difference?
The problem you pose could come up in the LMI software where a user
can make a (DEFUN FOO ...) turn into a %MISC instruction opcode
by using the microcompiler, but should be avoided by having redefined
%MISC instructions trap back to macrocode. The hard part is that
the actual number of arguments to the call is lost in the translation
to order-code, and klugely recovered by groveling through the debugging
info for the FEF being executed. The real problem is allocating the
limited opcode space, which right now is on a first-come-first-served
basis. (Microcompiled function need but turn into %MISC's but it is the
most efficient thing to turn into).
-gjc
∂22-Feb-86 1540 smh@mit-ems.ARPA reader # syntax and whitespace
Received: from MIT-EMS.ARPA by SU-AI.ARPA with TCP; 22 Feb 86 15:40:16 PST
Received: by mit-ems.ARPA (4.12/4.8) id AA14012; Sat, 22 Feb 86 17:35:46 est
Date: Sat, 22 Feb 86 17:35:46 est
From: Steven Haflich <smh@mit-ems.ARPA>
Message-Id: <8602222235.AA14012@mit-ems.ARPA>
To: common-lisp@su-ai
Subject: reader # syntax and whitespace
Is the reader required to accept whitespace between sharp dispatch
sequences and the "following arguments in some form" (CLtL p.351)? The
answer obviously is no for #\x but not so clear for others:
#s (foo a 1 b 2)
#2a ((1 2 3) (4 5 6))
#' (lambda (x) (* x 2))
The strong similarity of each such "syntax" to a normal list suggests
that the reader will recursively use normal read, which implies that
whitespace will be skipped. But should one rely on it across all
implementations? If so, what about these?
#+ lisp1.5
#: foo
#x f98e
#B 01110110
#3R 121211
These violate my aesthetic sense that single atoms are delimited by
whitespace. Even so, the last three are arguably more readable (to
humans) with the space.
I feel that for consistency leading whitespace ought explicitly be
defined as legal after all sharp dispatches *except* sharp-backslash.
∂22-Feb-86 2316 smh@mit-ems.ARPA readtable and # "syntax"
Received: from MIT-EMS.ARPA by SU-AI.ARPA with TCP; 22 Feb 86 23:16:04 PST
Received: by mit-ems.ARPA (4.12/4.8) id AA15642; Sun, 23 Feb 86 02:19:09 est
Date: Sun, 23 Feb 86 02:19:09 est
From: Steven Haflich <smh@mit-ems.ARPA>
Message-Id: <8602230719.AA15642@mit-ems.ARPA>
To: common-lisp@su-ai
Subject: readtable and # "syntax"
There are other ways in which reader # syntax is underspecified in
CLtL. Consider:
(setq r (copy-readtable))
(set-syntax-from-char #\( #\) r)
(set-syntax-from-char #\) #\( r)
In readtable r the parens should now have exchanged their normal
functions. When readtable r is in effect, which of the following is
correct reader syntax?
)defstruct foo a b( ;Ugh!
#S(foo 1 2)
or
)defstruct foo a b(
#S)foo 1 2(
The issue is not clear from CLtL, which avoids calling the text after #S
a "list" and just generally refers to "this syntax".
∂23-Feb-86 1037 FAHLMAN@C.CS.CMU.EDU reader # syntax and whitespace
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 23 Feb 86 10:37:44 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 23 Feb 86 13:38:52-EST
Date: Sun, 23 Feb 1986 13:38 EST
Message-ID: <FAHLMAN.12185705369.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Steven Haflich <smh@MIT-EMS.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: reader # syntax and whitespace
In-reply-to: Msg of 22 Feb 1986 17:35-EST from Steven Haflich <smh at mit-ems.ARPA>
I see nothing in the manual to suggest that whitespace is allowed
between a sharp-dispatch sequence and the associated arguments. It
seems needlessly confusing to specifically allow this in some cases,
where it clearly cannot work for others. In my opinion, it "is an
error" (or should be an error) to include such whitespace, and this
should not be done in portable code. Some implementations may tolerate
whitespace in some of these places, but they certainly sholdn't go out
of their way to do so.
-- Scott
∂23-Feb-86 1043 FAHLMAN@C.CS.CMU.EDU readtable and # "syntax"
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 23 Feb 86 10:43:42 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 23 Feb 86 13:45:08-EST
Date: Sun, 23 Feb 1986 13:45 EST
Message-ID: <FAHLMAN.12185706513.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Steven Haflich <smh@MIT-EMS.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: readtable and # "syntax"
In-reply-to: Msg of 23 Feb 1986 02:19-EST from Steven Haflich <smh at mit-ems.ARPA>
In readtable r the parens should now have exchanged their normal
functions. When readtable r is in effect, which of the following is
correct reader syntax?
)defstruct foo a b( ;Ugh!
#S(foo 1 2)
or
)defstruct foo a b(
#S)foo 1 2(
The issue is not clear from CLtL, which avoids calling the text after #S
a "list" and just generally refers to "this syntax".
I think that the stuff following the #S is a list, and in parsing it one
would use the bindings in the current readtable. So your second example
would be the correct one, in my opinion. That seems like the
intuitively consistent interpretation to me, if the word "intuitive" can
be used in the presence of so perverse an example.
-- Scott
∂24-Feb-86 0806 shebs%utah-orion@utah-cs.arpa Function Cell Follow-up
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 24 Feb 86 08:06:40 PST
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA02115; Mon, 24 Feb 86 09:08:40 MST
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA21481; Mon, 24 Feb 86 09:08:37 MST
Date: Mon, 24 Feb 86 09:08:37 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8602241608.AA21481@utah-orion.ARPA>
To: common-lisp@su-ai.arpa
Subject: Function Cell Follow-up
I found the discussion of rationales for function cells interesting.
The idea that different kinds of things should be allowed to have
separate name spaces seemed to be the strongest reason for function
cells, aside from compatibility.
Unfortunately, no one addressed my last two questions, which had to
do with implementing functions and values in terms of each other.
Perhaps I should point out some motivation. Today, it looks as if
Common Lisp and Scheme (in various dialects) are emerging as the two
chief alternatives in the Lisp world (sort of like Interlisp and
Maclisp once upon a time?). Those who discount Scheme as a competitor
should be aware that there are some very good Scheme implementations
out there now, and that it has a body of supporters many of whom are in
influential positions, i.e. as instructors in classes. At Utah for
instance, undergraduates get several courses using Scheme long before
they see Lisp, and many other places are similar. Consider another
"instructional" language - Pascal - and think about how many Pascal
programs have been inflicted on the world...
Anyway, despite appearances :-), I'm more of an ideologist than an
ideologue, and so I'm interested in just how incompatible Common Lisp
and Scheme *really* are, and how difficult it would be to implement
one in the other. It's certainly possible, but since I haven't actually
tried hacking all this out, I'm not clear on the pitfalls.
stan
∂24-Feb-86 1109 JAR@MC.LCS.MIT.EDU Function Cell Follow-up
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 24 Feb 86 11:09:40 PST
Date: Mon, 24 Feb 86 14:10:24 EST
From: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
Subject: Function Cell Follow-up
To: shebs@UTAH-ORION.ARPA
cc: common-lisp@SU-AI.ARPA
In-reply-to: Msg of Mon 24 Feb 86 09:08:37 MST from shebs%utah-orion at utah-cs.arpa (Stanley Shebs)
Message-ID: <[MC.LCS.MIT.EDU].828912.860224.JAR>
Date: Mon, 24 Feb 86 09:08:37 MST
From: shebs%utah-orion at utah-cs.arpa (Stanley Shebs)
Anyway, despite appearances :-), I'm more of an ideologist than an
ideologue, and so I'm interested in just how incompatible Common Lisp
and Scheme *really* are, and how difficult it would be to implement
one in the other. It's certainly possible, but since I haven't actually
tried hacking all this out, I'm not clear on the pitfalls.
I think the namespace problems are relatively easily overcome by
source-to-source translations, both going from Scheme to CL and from CL
to Scheme. Going one way you throw in a lot of FUNCALL's, and going the
other way you implement packages somehow and do some kludge to generate
names for variables which can stand for function bindings. The hard
problem in embedding Scheme in CL is tail recursion, which is impossible
to simulate in a natural way in portable Common Lisp. It may be more or
less easy in particular CL implementations (some are tail recursive
already, others may have compilers or stack-overflow handlers that can
be tweaked), but the only portable mechanism I know of is to do more or
less what Sussman and Steele's 1975 scheme interpreter did, which is to
use a driver loop of some kind, so that each procedure "returns" into
the driver loop in order to call another procedure at the same stack
level. This works but is quite unnatural and probably inefficient.
The hard technical problem in embedding CL in Scheme is implementing
multiple values smoothly. Various kludges are possible, such as the one
used by Maclisp, namely maintaining a set of global value registers.
Again, if you can hack the implementation directly, it can be pretty
straightforward (some already have multiple value returns internally).
A lesser problem is left-to-right argument evaluation, if CL ever
decides that that's necessary, but that can be forced using LET*.
∂24-Feb-86 1200 DCP@ALLEGHENY.SCRC.Symbolics.COM Function Cell Follow-up
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 24 Feb 86 12:00:10 PST
Received: from NEPONSET.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 784; Mon 24-Feb-86 15:00:23-EST
Date: Mon, 24 Feb 86 15:00 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: Function Cell Follow-up
To: Stanley Shebs <shebs%utah-orion@UTAH-CS.ARPA>,
common-lisp@SU-AI.ARPA
In-Reply-To: <8602241608.AA21481@utah-orion.ARPA>
Message-ID: <860224150024.6.DCP@NEPONSET.SCRC.Symbolics.COM>
Date: Mon, 24 Feb 86 09:08:37 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
I found the discussion of rationales for function cells interesting.
The idea that different kinds of things should be allowed to have
separate name spaces seemed to be the strongest reason for function
cells, aside from compatibility.
Unfortunately, no one addressed my last two questions, which had to
do with implementing functions and values in terms of each other.
With the correct language walking tools, it is possible to transform
Scheme code into Common Lisp code. Basically, if you see
FOO
in a 'variable' position, but the lexically apparent FOO is really a
function, transform it into #'FOO. If there is no lexically apparent
FOO, then look at the global definition of function and value and pick
the one that is defined. (This has order of definition and compiler
environment problems, of course.) Conversely, if you see FOO in
functional position, e.g., as (FOO ...) and FOO's innermost lexical
definition is as a 'variable' then transform this into (funcall foo ...).
I wrote such a tool before, but I have recently learned the usage of our
code walker was somewhat incorrect, so I sometimes might generate the
wrong answers.
As for implementing CL in Scheme, I don't have any experience, but I
think it could be done. [I learned Scheme in the '78-'79 academic year
and confess I haven't kept up on the language.] One way would be to put
the funtion on a property (a la Maclisp). There are a lot of details,
but I think function lookup is the hardest; all the rest are mostly
source level transforms.
∂24-Feb-86 1256 DCP@ALLEGHENY.SCRC.Symbolics.COM Function Cell Follow-up
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 24 Feb 86 12:56:29 PST
Received: from NEPONSET.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 790; Mon 24-Feb-86 15:56:42-EST
Date: Mon, 24 Feb 86 15:56 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: Function Cell Follow-up
To: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>, shebs@UTAH-ORION.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <[MC.LCS.MIT.EDU].828912.860224.JAR>
Message-ID: <860224155645.8.DCP@NEPONSET.SCRC.Symbolics.COM>
Is tail recursion REQUIRED of Scheme implementations, or is just in all
the papers because it is easy to do in most Scheme implementations.
∂24-Feb-86 1820 JAR@MC.LCS.MIT.EDU Function Cell Follow-up
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 24 Feb 86 18:20:10 PST
Date: Mon, 24 Feb 86 20:28:33 EST
From: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
Subject: Function Cell Follow-up
To: DCP@SCRC-QUABBIN.ARPA
cc: common-lisp@SU-AI.ARPA, shebs@UTAH-ORION.ARPA
In-reply-to: Msg of Mon 24 Feb 86 15:56 EST from David C. Plummer <DCP at SCRC-QUABBIN.ARPA>
Message-ID: <[MC.LCS.MIT.EDU].829401.860224.JAR>
Date: Mon, 24 Feb 86 15:56 EST
From: David C. Plummer <DCP at SCRC-QUABBIN.ARPA>
Is tail recursion REQUIRED of Scheme implementations, or is just in all
the papers because it is easy to do in most Scheme implementations.
It's absolutely as essential as garbage collection. (If you argue
against one you must argue against the other.) See page 8 of the MIT AI
memo 848 (the "revised revised report") and the abstract of memo 452
(the "revised report"). Also note that no mechanism other than function
call is supplied to implement iteration, and it would be absurd to limit
the number of iterations of a loop to a function of the space available
for stack.
(It was no easier or harder to do in "most scheme implementations" than
in implementations of any other language, except by virtue of having
been designed for; I don't quite understand the remark.)
∂24-Feb-86 1858 shebs%utah-orion@utah-cs.arpa Re: Function Cell Follow-up
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 24 Feb 86 18:58:17 PST
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA20999; Mon, 24 Feb 86 18:56:18 MST
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA26504; Mon, 24 Feb 86 18:56:14 MST
Date: Mon, 24 Feb 86 18:56:14 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8602250156.AA26504@utah-orion.ARPA>
To: DCP@scrc-quabbin.arpa, JAR@mc.lcs.mit.edu
Subject: Re: Function Cell Follow-up
Cc: common-lisp@su-ai.arpa
Date: Mon, 24 Feb 86 20:28:33 EST
From: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
Date: Mon, 24 Feb 86 15:56 EST
From: David C. Plummer <DCP at SCRC-QUABBIN.ARPA>
Is tail recursion REQUIRED of Scheme implementations, or is just in all
the papers because it is easy to do in most Scheme implementations.
It's absolutely as essential as garbage collection. [...]
I recall reading some old Lisp Machine papers that suggested
garbage collection should be avoided (DDI = Don't Do It!) :-) :-)
stan
∂25-Feb-86 0816 DCP@ALLEGHENY.SCRC.Symbolics.COM Things to consider for CLtL'97
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 25 Feb 86 08:15:15 PST
Received: from NEPONSET.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 860; Tue 25-Feb-86 11:15:32-EST
Date: Tue, 25 Feb 86 11:15 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: Things to consider for CLtL'97
To: Common-Lisp@SU-AI.ARPA
Message-ID: <860225111537.4.DCP@NEPONSET.SCRC.Symbolics.COM>
reduce should have a :KEY keyword argument. For example, suppose you
have a sequence of sequences, and you want to know the sum of the
lengths of the inner sequences. Currently, I think you have to do
(reduce #'(lambda (so-far subsequence)
(+ so-far (length sub-sequence)))
sequence)
but I would prefer to do
(reduce #'+ sequence :key #'length)
There should be a modify-seq (or some name) that looks roughly like
modify-seq sequence modifier &key start end from-end test test-not
that modifies the elements of the sequence between start and end that
past the TEST function. The element is replaced by the modifier applied
to the old element. For example, if a sequence is a sequence of
integers and you want to change it into a sequence of arrays whose
lengths are based on those integers, one could do
(modify-seq sequence #'(lambda (n) (make-array (round (* n 1.1)))))
There should be a modify-hash function.
∂26-Feb-86 1027 ANDY@SU-SUSHI.ARPA defmacro in let
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 26 Feb 86 10:27:29 PST
Date: Wed 26 Feb 86 10:27:27-PST
From: Andy Freeman <ANDY@SU-SUSHI.ARPA>
Subject: defmacro in let
To: common-lisp@SU-AI.ARPA
Message-ID: <12186489734.14.ANDY@SU-SUSHI.ARPA>
The following is legal Common Lisp.
(let ((tag (gensym)))
(defun foo ()
tag))
What about this? (Yes, this example is stupid, but there are uses of
the idea that aren't.)
(let ((tag (gensym)))
(defmacro foo ()
tag))
What about defsetf's inside top-level lets?
-andy
-------
∂26-Feb-86 1520 JAR@MC.LCS.MIT.EDU What does LOAD use for read table & package?
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 26 Feb 86 15:20:39 PST
Date: Wed, 26 Feb 86 18:07:59 EST
From: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
Subject: What does LOAD use for read table & package?
To: common-lisp@SU-AI.ARPA
Message-ID: <[MC.LCS.MIT.EDU].831718.860226.JAR>
I'm trying to write a portable program which wants to use LOAD and
COMPILE-FILE with a particular read table and package not specified by
eval-when's or other forms in the file. I'm not at liberty to edit the
file, and I don't want to bother writing out an intermediate file
(besides being slow, redundant, and impossible to do portably, that
screws up whatever record the CL implementation might be keeping of the
source file for definitions). But in the implementation I'm using, LOAD
and COMPILE-FILE absoluetly insist on ignoring the binding of readtable
and package, and defaulting them to I don't know what. (The files don't
have attribute lists.)
CLtL is not explicit on this point. Is LOAD required to pay attention
to the bindings of *READTABLE* and *PACKAGE*? If so, I can report a bug
and look forward to a fix N years hence. Many people will say "no" just
because they want their LOAD to attend to the -*- attribute list, but
what if there isn't any attribute list? Maybe there should be
:readtable and :package keyword arguments to LOAD and COMPILE-FILE, to
override defaults that the system might have? Or am I just going to
have to lose completely here?
Jonathan Rees.
∂26-Feb-86 1814 ANDY@SU-SUSHI.ARPA Re: defmacro in let
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 26 Feb 86 18:13:56 PST
Date: Wed 26 Feb 86 17:35:58-PST
From: Andy Freeman <ANDY@SU-SUSHI.ARPA>
Subject: Re: defmacro in let
To: NGALL@BBNG.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <[G.BBN.COM]26-Feb-86 20:12:49.NGALL>
Message-ID: <12186567743.9.ANDY@SU-SUSHI.ARPA>
I've now read and understood page 145. My question should be answered
RTFM; I have mailed myself 100 copies of this, saving those of you so
inclined the effort. (If you do this my way, you'll avoid polluting
the entire common-lisp mailing list.)
-andy thinks the difference in the environments for defun and defmacro
is silly but that the time for discussion has long passed
-------
∂26-Feb-86 1820 NGALL@G.BBN.COM Re: defmacro in let
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 26 Feb 86 18:19:54 PST
Date: 26 Feb 1986 20:12-EST
Sender: NGALL@G.BBN.COM
Subject: Re: defmacro in let
From: NGALL@G.BBN.COM
To: ANDY@SU-SUSHI.ARPA
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]26-Feb-86 20:12:49.NGALL>
In-Reply-To: <12186489734.14.ANDY@SU-SUSHI.ARPA>
Date: Wed 26 Feb 86 10:27:27-PST
From: Andy Freeman <ANDY@SU-SUSHI.ARPA>
To: common-lisp@SU-AI.ARPA
Subject: defmacro in let
Message-ID: <12186489734.14.ANDY@SU-SUSHI.ARPA>
The following is legal Common Lisp.
(let ((tag (gensym)))
(defun foo ()
tag))
What about this? (Yes, this example is stupid, but there are uses of
the idea that aren't.)
(let ((tag (gensym)))
(defmacro foo ()
tag))
It is legal, but TAG is considered a special (i.e., the enclosing lexical
env. is ignored). See pg 145.
What about defsetf's inside top-level lets?
Unclear from the text how free references should be handled. Since it
"resembles DEFMACRO" (pg. 103) I'd go with my answer above. Should be
clarified though.
-andy
-------
--------------------
-- Nick
∂26-Feb-86 1828 FAHLMAN@C.CS.CMU.EDU What does LOAD use for read table & package?
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 26 Feb 86 18:28:00 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 26 Feb 86 20:59:10-EST
Date: Wed, 26 Feb 1986 20:36 EST
Message-ID: <FAHLMAN.12186567869.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
Cc: common-lisp@SU-AI.ARPA
Subject: What does LOAD use for read table & package?
In-reply-to: Msg of 26 Feb 1986 18:07-EST from Jonathan A Rees <JAR at MC.LCS.MIT.EDU>
I think that the manual is silent on what readtable and package should
be used by load. Let's think about what the right thing would be.
It seems to me that, insofar as it is possible, we want to set things up
so that loading a compiled file has the same effect as loading the
source file. This says to me that if the source file uses In-Package to
specify the package to be used, the compiler should emit something in
the compiled-code file that makes this package current while the file is
being loaded. If the source file does not explicitly specify a package,
it should be loaded into whatever package is current when Load is
called.
(The "-*-" convention is not a part of Common Lisp and should not be
used by itself to set up packages in portable code. It is significant
to certain editors and other implementation-specific tools.)
In the case of loading uncompiled code files, the same thing would be
true: the in-package statement would govern, and if it is absent the
current package would be used by LOAD.
It would be nice to say the same thing for readtables -- use the current
one unless the file specifies otherwise -- but this is impractical.
Almost all of what a readtable does is done while the compiler is
reading the source file, at a time when the compiler has no way of
knowing what readtable will be current when the object file is loaded.
The loading of compiled code has little, if anything, to do with the
reader, so I think the question of whether to use the current or the
defautl readtable during such loads is moot.
So in the case of readtables, it comes down to a question of what Load
should do when loading uncompiled files. I'm inclined to think that the
current readtable should be used, even though this will have different
effects when loading a source file or the corresponding fasl file. We
should advise users that the readtable should be the way they want it at
COMPILE time if it is to effect code being compiled, because load time
is too late.
-- Scott
∂27-Feb-86 0618 greek%bach.decnet@hudson.dec.com Loading into the current package.
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 27 Feb 86 06:18:37 PST
Date: 0 0 00:00:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: Loading into the current package.
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
I agree pretty much with what Scott has to say about packages and
readtables when loading. However, I believe there is at least one
important ambiguity. Take the following program:
; Absolutely no mention of packages
.
.
foo
P1::bar
Now let's say that's compiled in package P1. Once the reader is done,
both symbols will be in package P1. The compiler won't be able to tell
that one was unqualified and one was explicitly qualified with P1, so
they both look unqualified.
And then the fastload file is loaded into package P2. Oops! Assuming
the compiler causes unqualified symbols to end up in the current
package, then both will end up in P2. Or, if it causes unqualified
symbols to end up in the package in which the compilation was performed,
then both will end up in P1 (which may not even be around).
There is something wrong with a file that doesn't mention packages.
This is just the rim of the compilation environment wormcan.
- Paul
------
∂27-Feb-86 0816 shebs%utah-orion@utah-cs.arpa Documentation Strings in Lambdas
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 27 Feb 86 08:16:35 PST
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA11420; Thu, 27 Feb 86 09:18:42 MST
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA02746; Thu, 27 Feb 86 09:18:40 MST
Date: Thu, 27 Feb 86 09:18:40 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8602271618.AA02746@utah-orion.ARPA>
To: common-lisp@su-ai.arpa
Subject: Documentation Strings in Lambdas
It is implied on p. 60 that documentation strings are allowed in anonymous
lambdas. Is this just for simplicity/consistency, so that things like
defun can macroexpand without having to grovel around excising documentation
strings?
stan
∂27-Feb-86 0929 snyder@hplsny Re: What does LOAD use for read table & package?
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 27 Feb 86 09:28:49 PST
Received: from hplsny by hplabs.ARPA ; Thu, 27 Feb 86 09:28:09 pst
Received: by hplsny ; Thu, 27 Feb 86 09:28:01 pst
From: Alan Snyder <snyder@hplsny>
Message-Id: <8602271728.AA02879@hplsny>
Date: Thursday, February 27, 1986 09:27:57
Subject: Re: What does LOAD use for read table & package?
To: common-lisp@su-ai.ARPA
In-Reply-To: Your message of 26-Feb-86 20:36:00
X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46
It seems to me that, insofar as it is possible, we want to set things up
so that loading a compiled file has the same effect as loading the
source file.
If the source file does not explicitly specify a package,
it should be loaded into whatever package is current when Load is
called.
I don't think that compiled/uncompiled code consistency can be used to resolve
this issue. One could just as easily say that loading either a source file or
a compiled file should start in some "standard" package (e.g. "USER").
My own bias is that all source files be self-descriptive in the sense of
specifying the environment they need (package, readtable, required modules,
etc.).
Perhaps both alternatives should be supported. We could define LOAD to start
in a known state (package, readtable) and define a new function INCLUDE that
uses the current environment. If the model for INCLUDE is "behave as if the
referenced text were directly included here" then it might also differ from
LOAD by (1) not restoring *PACKAGE* when it is done and (2) being implicitly
evaluated by the compiler like INCLUDE in other languages.
-------
∂27-Feb-86 1118 Moon@ALLEGHENY.SCRC.Symbolics.COM What does LOAD use for read table & package?
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 27 Feb 86 11:18:16 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 1302; Thu 27-Feb-86 14:18:22-EST
Date: Thu, 27 Feb 86 14:15 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: What does LOAD use for read table & package?
To: common-lisp@SU-AI.ARPA
In-Reply-To: <[MC.LCS.MIT.EDU].831718.860226.JAR>
Message-ID: <860227141510.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
I believe that the only viable possibility for LOAD of a compiled file
is to bind *PACKAGE* to the same value that it had when the file was
compiled. This means that the compiler must transmit this information
to the loader in some way. If there are SETQs of *PACKAGE* in the
source file (perhaps disguised as IN-PACKAGE), then they should do the
same thing at load time as they did at compile time.
This is obviously an area where the language definition could use a lot
of tightening up. The issues are not simple, especially if one is unwilling
to learn from experience.
∂27-Feb-86 1529 kim@im4u.utexas.edu desperately seeking Lisp hackers
Received: from IM4U.UTEXAS.EDU by SU-AI.ARPA with TCP; 27 Feb 86 15:29:25 PST
Date: Thu, 27 Feb 86 17:22:32 cst
From: kim@im4u.utexas.edu (Hyoung-Joo Kim, DB person)
Posted-Date: Thu, 27 Feb 86 17:22:32 cst
Message-Id: <8602272322.AA14338@im4u>
Received: by im4u (4.22/4.22)
id AA14338; Thu, 27 Feb 86 17:22:32 cst
To: common-lisp@SU-AI.ARPA
Subject: desperately seeking Lisp hackers
Cc: kim@im4u.utexas.edu
MCC CAD Database Group is loking for real Lisp hackers.
I got the following advertisement last week.
-------------------------------------------------
Summer Job Opportunities with MCC
We have summer openings for students experienced in LISP
programming. The project involves programming in Common
LISP various modules of a reserach prototype database
system that will run on a Symbolics LISP machine.
LISP programming experiences are required.
Experiences with Common-LISP, Symbolics LISP machine,
or database system architecture are preferred, but not required.
Enquires should be directed to:
Dr. Won Kim
MCC
9430 Research Blvd.
Austin, Texas 78759
(512) 834-3439
-------------------------------------------------
∂27-Feb-86 1741 FAHLMAN@C.CS.CMU.EDU What does LOAD use for read table & package?
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 27 Feb 86 17:40:54 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 27 Feb 86 20:41:00-EST
Date: Thu, 27 Feb 1986 20:40 EST
Message-ID: <FAHLMAN.12186830790.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: What does LOAD use for read table & package?
In-reply-to: Msg of 27 Feb 1986 14:15-EST from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
I believe that the only viable possibility for LOAD of a compiled file
is to bind *PACKAGE* to the same value that it had when the file was
compiled. This means that the compiler must transmit this information
to the loader in some way. If there are SETQs of *PACKAGE* in the
source file (perhaps disguised as IN-PACKAGE), then they should do the
same thing at load time as they did at compile time.
For those of us who want to learn from your experience, could you
elaborate a bit on the above pronouncement? Why is it a good idea to
bind *PACKAGE* to the compile-time value, rather than using what is
current at load time? What if the compile-time package doesn't exist at
load time?
-- Scott
∂28-Feb-86 0016 REM%IMSSS.#Pup@SU-SCORE.ARPA PACKAGE, READTABLE, etc. in compiled files vs. load uncompiled
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 28 Feb 86 00:16:52 PST
Received: from IMSSS by Score with Pup; Fri 28 Feb 86 00:17:26-PST
Date: 28 Feb 1986 0015-PST
From: Rem@IMSSS
Subject: PACKAGE, READTABLE, etc. in compiled files vs. load uncompiled
To: COMMON-LISP%SU-AI@SCORE
It seems clear from the plethora of proposals that somebody should collect
all the proposals, as strawmen, and see which can be knocked down and
which look like they might be workable; perhaps compile a document summarizing
each proposal succinctly and summarizing bugs in proposal succinctly.
Then if we have all these proposals and rebuttals in one document somebody
can figure out what really should be done and write one final strawman
proposal for everyone to consider adopting.
Otherwise we seem to be going in circles with all these random proposals
and flat-out ultimatum statements about how it should work.
-------
∂28-Feb-86 0559 greek%bach.decnet@hudson.dec.com Collecting proposals for packages, readtables, etc.
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 28 Feb 86 05:58:59 PST
Date: 0 0 00:00:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: Collecting proposals for packages, readtables, etc.
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
I certainly can't argue that collecting all the proposals so that we
can see them together is a bad idea. But this really is a big project.
I think we are dancing around a lot of tough issues:
o What exactly is the compilation environment.
o How is the LISP environment affected by a compilation.
o How are multiple files/modules built into a large system.
o How does the compilation environment compare to the load environment.
o Etc.
These questions must be answered in concert, with thought given to the
whole problem of the LISP environment. I'd be willing to bet that an
answer to one or two simpler problems would seem reasonable, but when
placed in the larger context might be totally wrong.
I was struck by a simple comment someone made: The right thing for the
compiler to do is to clone the LISP environment, do the compilation, and
discard the clone; however, this is not what people expect or want.
Is there an environment committee? If not, does it make sense to start one?
- Paul
------
∂28-Feb-86 0639 FAHLMAN@C.CS.CMU.EDU Environment Committee
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 28 Feb 86 06:37:02 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 28 Feb 86 09:37:34-EST
Date: Fri, 28 Feb 1986 09:37 EST
Message-ID: <FAHLMAN.12186972150.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Environment Committee
[I can't respond to Paul the Greek directly. All the mail from DEC in
the last couple of weeks has arrived with headers all screwed up and
with the body smashed into the header. I'm surprised it arrived at
all. OF course, the problem might be on our end, but only mail from DEC
seems to be losing.]
Paul,
I agree that there are many things that need to be sorted out in the
compilation area. We really let that slide the first time around.
There is not currently an environmnet committee, and I don't think that
one is likely to be fruitful. At best we could hope for N different
classes of environment, each fairly well-defined. Things are totally
different depending on whether your system supports multiple windows,
whether you are in an Emacs or internal-editing culture, and so on.
Initially we even wanted to leave open the question of whether the
compiler was written in Lisp, though I don't think anyone has exercised
the option not to do this and we may want to put that particular freedom
to rest.
What we do need to do is work on specifying those aspects of compilation
that affect what goes into a portable code file (or set of files) and
what the items in that file mean. We can and must nail down compiler
issues of that sort before a standard is finished.
It is interesting that the EuLisp people have decided to try to specify
an environmnet along with their Lisp, using a multi-level spec ranging
from very simple (appropriate for a Z-80 based machine) to very complex
(presumably comparable in scope to what is in Zetalisp or Interlisp).
They have fewer constraints in the way of existing groups who want to
stick with their own environment conventions, but they are trying to do
this for an awfully big spread of machines. It will be interesting to
see what they come up with.
-- Scott
∂28-Feb-86 0819 greek%bach.decnet@hudson.dec.com LISP Environment.
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 28 Feb 86 08:19:01 PST
Date: 0 0 00:00:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: LISP Environment.
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
First of all, an apology to anyone receiving butchered mail from us
at DEC. We're using some software by an Australian-sounding company
that seems to have some problems.
Well, Scott, I certainly agree that specifying an entire environment is
a tough problem. Perhaps then, as has been suggested, someone should
write down all the individual questions that we need to answer. Then
everyone would know what to think about. At least those questions
which we do answer would be consistent and play together.
If people want to send me their favorite compilation environment
QUESTIONS, I'd be happy to compile a complete list and send it out
to everyone.
- Paul
------
∂28-Feb-86 1006 JAR@MC.LCS.MIT.EDU Collecting proposals for packages, readtables, etc.
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 28 Feb 86 10:06:25 PST
Date: Fri, 28 Feb 86 13:07:08 EST
From: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
Subject: Collecting proposals for packages, readtables, etc.
To: common-lisp@SU-AI.ARPA
In-reply-to: Msg of 0 0 00:00:00 EST from BACH::GREEK <greek%bach.decnet at hudson.dec.com>
Message-ID: <[MC.LCS.MIT.EDU].833953.860228.JAR>
While the discussion about the relationship between compilation
environment and load environment has been interesting, and the problem
is important (and probably insoluble, given CL's compilation and
modularity paradigms), I want to point out that my message of a couple
days ago, which apparently started this, was asking something very
different and much simpler. I simply want to be able to set the
readtable (and package) with which a *source* file will be *read* by
COMPILE-FILE and LOAD. Symbolics Common Lisp gives me no way to do
this, and I wanted to know whether people felt that CL was defined in
such a way that COMPILE-FILE and LOAD, in the absence of standard
(IN-PACKAGE, EVAL-WHEN, etc.) and nonstandard (-*- Syntax: ... -*-)
bindings of package and readtable, are required to respect the bindings
in effect when they are invoked. If so, then I should report a bug in
Symbolics Common Lisp.
- Jonathan
∂28-Feb-86 1039 gls@THINK-AQUINAS.ARPA Function cells
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 28 Feb 86 10:37:42 PST
Received: from guido by GODOT.THINK.COM via CHAOS; Fri, 28 Feb 86 13:37:45 est
Date: Fri, 28 Feb 86 13:39 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Function cells
To: DCP@SCRC-QUABBIN.ARPA, gls@THINK-AQUINAS.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <860220182741.9.DCP@NEPONSET.SCRC.Symbolics.COM>
Message-Id: <860228133929.1.GLS@GUIDO.THINK.COM>
Date: Thu, 20 Feb 86 18:27 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Date: Wed, 19 Feb 86 15:40 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
...
I can report that much of the time I am very happy to have the two names
spaces be distinct. I get very unhappy whenever I find myself inventing
functionals (functions that take other functions as arguments or return
other functions as values) for various purposes. For example, I have
found it semantically convenient to do so in Connection Machine Lisp.
In these situations I find the need for interpolated occurrences of
"funcall" and "#'" extremely annoying.
I read this last paragraph 3 times and am under the impression you
change your mind on each sentence. I'm really curious what you meant!
What I meant is: (a) much of the time I am happy; (b) the part of the time
I am not happy, it is in the following circumstances (trying to use functionals).
--Guy
∂28-Feb-86 1127 @SCRC-QUABBIN.ARPA,@EUPHRATES.SCRC.Symbolics.COM:Moon@SCRC-STONY-BROOK.ARPA What does LOAD use for read table & package?
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 28 Feb 86 11:27:12 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via INTERNET with SMTP id 249286; 28 Feb 86 14:24:31-EST
Date: Fri, 28 Feb 86 14:24 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: What does LOAD use for read table & package?
To: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12186830790.BABYL@C.CS.CMU.EDU>
Message-ID: <860228142427.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 27 Feb 1986 20:40 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I believe that the only viable possibility for LOAD of a compiled file
is to bind *PACKAGE* to the same value that it had when the file was
compiled. This means that the compiler must transmit this information
to the loader in some way. If there are SETQs of *PACKAGE* in the
source file (perhaps disguised as IN-PACKAGE), then they should do the
same thing at load time as they did at compile time.
For those of us who want to learn from your experience, could you
elaborate a bit on the above pronouncement? Why is it a good idea to
bind *PACKAGE* to the compile-time value, rather than using what is
current at load time?
The READ operations that the compiler does lose information about what package
prefixes were specified on symbols. The compiler has to put something in its
output file that expresses the identity of those symbols, and the loader has to
take that information in the file and reproduce the same symbols. (Perhaps
I should stop here and ask if you agree that the desired semantics is for loading
the compiled file to refer to the same symbols as loading the source file.)
In my experience, the way that produces the least surprise for users is for the
compiler to record symbols in its output file using the same algorithm as PRINT
to decide when to put a package prefix, and for the loader to use the same
algorithm as READ to interpret those prefixes, relative to the same package with
respect to which they were printed. We have tried other techniques, such as
always putting a package prefix in the compiler's output file, and found them
deficient. The problem with always putting a package prefix is that almost any
change to the package structure (what symbol is exported from where, or what is
the home package of a symbol that is in multiple packages) will prevent the
compiled file from loading correctly.
We do have a way to force LOAD to load into a different package than the
one the file was compiled in, using a :PACKAGE keyword argument, but in
practice this is rarely used.
What if the compile-time package doesn't exist at load time?
Then the program doesn't load. I don't see this as any different from calling
a function that doesn't exist at load time. I also don't see this as surprising,
since in my view the compile-time package is very much part of the program, not
an accidental detail of compilation, and it would be unusual for it not to exist
at load time. Of course any mechanism, such as IN-PACKAGE or -*-, that tells the
compiler to create the package if it does not already exist should be transmitted
to the loader, which should also create the package if it does not already exist.
-------
This is of course only a tiny part of the whole issue of compilation and
environments. I think it very unlikely that we will be able to agree on
full details of programming environments, since Common Lisp is being
implemented on such a wide range of systems with different capabilities
and different goals. In fact such agreement would be undesirable in my
view, since it would either exclude a large sector of the Common Lisp
community or would require a least-common-denominator programming
environment that would be of little use to those among my users who are
tackling extremely ambitious projects in Lisp. I agree with what you
said in another message that the important thing is to focus on what is
necessary to write portable programs.
∂28-Feb-86 1144 gls@THINK-AQUINAS.ARPA Re: Function Cell Follow-up
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 28 Feb 86 11:42:46 PST
Received: from guido by GODOT.THINK.COM via CHAOS; Fri, 28 Feb 86 14:42:30 est
Date: Fri, 28 Feb 86 14:44 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Re: Function Cell Follow-up
To: shebs%utah-orion@UTAH-CS.ARPA, DCP@SCRC-QUABBIN.ARPA, JAR@mc.lcs.mit.edu
Cc: common-lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA
In-Reply-To: <8602250156.AA26504@utah-orion.ARPA>
Message-Id: <860228144414.6.GLS@GUIDO.THINK.COM>
Date: Mon, 24 Feb 86 18:56:14 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Date: Mon, 24 Feb 86 20:28:33 EST
From: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
Date: Mon, 24 Feb 86 15:56 EST
From: David C. Plummer <DCP at SCRC-QUABBIN.ARPA>
Is tail recursion REQUIRED of Scheme implementations, or is just in all
the papers because it is easy to do in most Scheme implementations.
It's absolutely as essential as garbage collection. [...]
I recall reading some old Lisp Machine papers that suggested
garbage collection should be avoided (DDI = Don't Do It!) :-) :-)
stan
Probably you are thinking of JONL White's paper in the 1980 Lisp Conference.
--Guy
∂28-Feb-86 1204 gls@THINK-AQUINAS.ARPA Things to consider for CLtL'97
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 28 Feb 86 12:02:32 PST
Received: from guido by GODOT.THINK.COM via CHAOS; Fri, 28 Feb 86 15:02:26 est
Date: Fri, 28 Feb 86 15:04 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Things to consider for CLtL'97
To: DCP@SCRC-QUABBIN.ARPA, Common-Lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <860225111537.4.DCP@NEPONSET.SCRC.Symbolics.COM>
Message-Id: <860228150412.8.GLS@GUIDO.THINK.COM>
Date: Tue, 25 Feb 86 11:15 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
reduce should have a :KEY keyword argument. For example, suppose you
have a sequence of sequences, and you want to know the sum of the
lengths of the inner sequences. Currently, I think you have to do
(reduce #'(lambda (so-far subsequence)
(+ so-far (length sub-sequence)))
sequence)
but I would prefer to do
(reduce #'+ sequence :key #'length)
(REDUCE #'+ (MAP (TYPE-OF sequence) #'length sequence))
There should be a modify-seq (or some name) that looks roughly like
modify-seq sequence modifier &key start end from-end test test-not
that modifies the elements of the sequence between start and end that
past the TEST function. The element is replaced by the modifier applied
to the old element. For example, if a sequence is a sequence of
integers and you want to change it into a sequence of arrays whose
lengths are based on those integers, one could do
(modify-seq sequence #'(lambda (n) (make-array (round (* n 1.1)))))
There should be a modify-hash function.
This isn't consistent with the syntax of other functions that have a test.
Did you mean:
modify-seq item sequence modifier &key start end from-end test test-not
modify-seq-if predicate sequence modifier &key start end from-end
modify-seq-if-not item sequence modifier &key start end from-end
? And should they all also take a :KEY argument?
--Guy
∂28-Feb-86 1406 DCP@ALLEGHENY.SCRC.Symbolics.COM Things to consider for CLtL'97
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 28 Feb 86 14:06:07 PST
Received: from NEPONSET.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 1624; Fri 28-Feb-86 17:06:10-EST
Date: Fri, 28 Feb 86 17:06 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: Things to consider for CLtL'97
To: Guy Steele <gls@THINK-AQUINAS.ARPA>, DCP@SCRC-QUABBIN.ARPA,
Common-Lisp@SU-AI.ARPA
In-Reply-To: <860228150412.8.GLS@GUIDO.THINK.COM>
Message-ID: <860228170643.0.DCP@NEPONSET.SCRC.Symbolics.COM>
Date: Fri, 28 Feb 86 15:04 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Date: Tue, 25 Feb 86 11:15 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
reduce should have a :KEY keyword argument. For example, suppose you
have a sequence of sequences, and you want to know the sum of the
lengths of the inner sequences. Currently, I think you have to do
(reduce #'(lambda (so-far subsequence)
(+ so-far (length sub-sequence)))
sequence)
but I would prefer to do
(reduce #'+ sequence :key #'length)
(REDUCE #'+ (MAP (TYPE-OF sequence) #'length sequence))
Yours conses. Mine doesn't.
There should be a modify-seq (or some name) that looks roughly like
modify-seq sequence modifier &key start end from-end test test-not
that modifies the elements of the sequence between start and end that
past the TEST function. The element is replaced by the modifier applied
to the old element. For example, if a sequence is a sequence of
integers and you want to change it into a sequence of arrays whose
lengths are based on those integers, one could do
(modify-seq sequence #'(lambda (n) (make-array (round (* n 1.1)))))
There should be a modify-hash function.
This isn't consistent with the syntax of other functions that have a test.
Did you mean:
[I assume this is in response to modify-seq instead of modify-hash.]
modify-seq item sequence modifier &key start end from-end test test-not
modify-seq-if predicate sequence modifier &key start end from-end
modify-seq-if-not predicate item sequence modifier &key start end from-end
?
I see, I think. Yes, I want the -IF and -IF-NOT forms as well.
And should they all also take a :KEY argument?
I don't think so. Consider what :KEY does. It extracts a part of the
datastructure. To put it back, the implementation would have to do
something like
(setf (funcall key sequence-element)
(funcall modifier
(funcall key sequence-element)))
and SETF of FUNCALL isn't generally invertable.
∂28-Feb-86 1833 FAHLMAN@C.CS.CMU.EDU Collecting proposals for packages, readtables, etc.
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 28 Feb 86 18:33:42 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 28 Feb 86 21:34:04-EST
Date: Fri, 28 Feb 1986 21:34 EST
Message-ID: <FAHLMAN.12187102599.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
Cc: common-lisp@SU-AI.ARPA
Subject: Collecting proposals for packages, readtables, etc.
In-reply-to: Msg of 28 Feb 1986 13:07-EST from Jonathan A Rees <JAR at MC.LCS.MIT.EDU>
I simply want to be able to set the
readtable (and package) with which a *source* file will be *read* by
COMPILE-FILE and LOAD.
Pending a resolution of these heavy issues, I would say that in a Lisp
where Compile-File and/or Load uses the current package and readtable,
there's no problem in rebinding this before doing the call. Any Lisp in
which Compile-File and/or Load insist on binding the package to some
particular value should allow this to be over-ridden, presumably by a
:package keyword argument. Moon says that Symbolics has this already.
-- Scott
∂28-Feb-86 2258 apollo!dfm@uw-beaver.arpa (satisfies predicate-name)
Received: from UW-BEAVER.ARPA by SU-AI.ARPA with TCP; 28 Feb 86 22:58:11 PST
Received: by uw-beaver.arpa (4.42/4.2)
id AA12446; Fri, 28 Feb 86 23:04:02 PST
Return-Path: <apollo!dfm@uw-beaver.arpa>
Message-Id: <8603010704.AA12446@uw-beaver.arpa>
From: apollo!dfm@uw-beaver.arpa
Date: Fri, 28 Feb 86 16:18:48 EST
Subject: (satisfies predicate-name)
To: common-lisp@su-ai.arpa
Apologies if this has been discussed before.
On page 43, discussing (satisfies predicate-name), CLtL says "A name is required;
lambda-expressions are disallowed in order to avoid scoping problems." Am I correct
in assuming that the global function definition is always to be used? For example,
I assume the following should not signal an error:
(defun f (x) t)
(labels ((f (x) nil))
(type-check nil (satisfies f)) )
Is that correct?
- Don Morrison
∂01-Mar-86 0528 GJC@MC.LCS.MIT.EDU What does LOAD use for read table & package?
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 1 Mar 86 05:28:44 PST
Date: Sat, 1 Mar 86 08:29:32 EST
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Subject: What does LOAD use for read table & package?
To: Fahlman@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA
In-reply-to: Msg of Wed 26 Feb 1986 20:36 EST from Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
Message-ID: <[MC.LCS.MIT.EDU].834927.860301.GJC>
You should not be so quick to say that the "-*-" shouldnt be used. It
may be ugly but experience has shown that it works very well. I know
of some common-lisp portable DEFSYSTEM/UNIX-MAKE-like programs that
first open the file and parse the "-*-" line and then bind
package,readtable, etc before calling the compiler and/or loader.
(And, similarily I have had to put code in the (LMI) lispmachine "-*-" parser
to scan the first part of a file to look for the idiomatic use of
IN-PACKAGE). Already I have had my fill of seeing the most grossly ad-hoc and
insufficient system-building programs in use by people that did at
least part of their program development work in the immature
non-Lispmachine environments and then have trouble dealing with the
more formal tools on the lispmachines. Does any emacs editor with
COMPILE-DEFUN really deal with multiple *package* SETQ's (In-Package)
throughout a file?
On the other hand, there are people with good portable system building tools,
(that they have put a significant amount of work into) and these people
wont be screwed by the lack of such things in the base CL.
∂01-Mar-86 2131 FAHLMAN@C.CS.CMU.EDU What does LOAD use for read table & package?
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 1 Mar 86 21:31:05 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 2 Mar 86 00:31:37-EST
Date: Sun, 2 Mar 1986 00:31 EST
Message-ID: <FAHLMAN.12187397057.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Cc: common-lisp@SU-AI.ARPA
Subject: What does LOAD use for read table & package?
In-reply-to: Msg of 1 Mar 1986 08:29-EST from George J. Carrette <GJC at MC.LCS.MIT.EDU>
You should not be so quick to say that the "-*-" shouldnt be used. It
may be ugly but experience has shown that it works very well.
It is fine with me if people want to put funny-looking comments into
their code and if certain implementation-specific tools such as editors
want to pay attention to such comments. We can even discuss whether the
"-*-" convention should be given some sort of official status within
Common Lisp. I'm glad we agree that it is ugly. If we want to specify
some Lisp-accessible attributes of a file, I would certainly hope that
we could do better than retaining this ugly kludge that has,
unfortunately, been around long enough that people have become used to
it.
But all of that is irrelevant to the point I was making. Let me try
again: There is no mention of "-*-" comments anywhere in the current
definition of Common Lisp. As far as Common Lisp is concerned,
everything in a comment is ignored. Any code that depends for its
correct interpretation on the "-*-" not being ignored is not portable
Common Lisp. Therefore, depending on this construct to set up packages
and the like should be avoided in code that is intended to be portable.
That's what In-Package is for.
-- Scott
∂01-Mar-86 2325 RWK@ALLEGHENY.SCRC.Symbolics.COM Loading into the current package.
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 1 Mar 86 23:25:46 PST
Received: from CROW.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 1745; Sun 2-Mar-86 02:26:01-EST
Date: Sun, 2 Mar 86 02:20 EST
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
Subject: Loading into the current package.
To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
cc: common-lisp <common-lisp@SU-AI.ARPA>
In-Reply-To: The message from "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Message-ID: <860302022030.2.RWK@CROW.SCRC.Symbolics.COM>
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
There is something wrong with a file that doesn't mention packages.
This is just the rim of the compilation environment wormcan.
I think this is the key point. I wouldn't dream of
creating a Lisp file without that -*- line at the top.
Even my programs which write Lisp files put it on there.
But I'd like to take a bite out of your wormcan. I think
we're being silly, scaring ourselves with "compilation
environments are a hard issue." The Europeans are tackling
it, if I understand my mail rightly, and if we just address
the specific problems, rather than throwing up our hands, I
believe we can make forward progress.
Surely we can come up with some standard syntax for
specifying this information, in a way that isn't completely
broken for systems with editors. I see three approaches:
1) restrict IN-PACKAGE, IMPORT, and friends to be at the start
of the file, before any other forms.
2) combine this stuff into a single declarative form at the top
of the file. (declarative = non-evaluating).
3) -*- or similar syntax.
We could also argue forever, or we could ignore the problem.
But that doesn't make IN-PACKAGE any less of a useless crock
that fails to live up to its compatibility goals. Unless there
is a language-specification change, "portable" CL files will
only be portable in a very narrow sense, and the reader of the
Steele Grey Book won't even know there's an issue.
∂03-Mar-86 0440 GJC@MC.LCS.MIT.EDU What does LOAD use for read table & package?
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 3 Mar 86 04:40:42 PST
Date: Mon, 3 Mar 86 07:41:29 EST
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Subject: What does LOAD use for read table & package?
To: Fahlman@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA
In-reply-to: Msg of Sun 2 Mar 1986 00:31 EST from Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
Message-ID: <[MC.LCS.MIT.EDU].836491.860303.GJC>
Looking back through the *anals* (sic) of BUG-LISPM at MIT you will find
my objections to the the "-*-" crock too. But you dont get the point of
my suggestion:
"To be actually suggesting that users can use -*- without fear,
and that it IS PORTABLE. This is because there are many
machines that support it now in a consistent way, and since
other machines IGNORE it then users are free to implement it
themselves."
Any of RWK's suggestions would be easy to implement and very servicable
to the community, in my experience.
-gjc
∂03-Mar-86 0741 gls@THINK-AQUINAS.ARPA Things to consider for CLtL'97
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 3 Mar 86 07:41:08 PST
Received: from guido by GODOT.THINK.COM via CHAOS; Mon, 3 Mar 86 10:41:39 est
Date: Mon, 3 Mar 86 10:43 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Things to consider for CLtL'97
To: DCP@SCRC-QUABBIN.ARPA, gls@THINK-AQUINAS.ARPA, Common-Lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <860228170643.0.DCP@NEPONSET.SCRC.Symbolics.COM>
Message-Id: <860303104332.1.GLS@GUIDO.THINK.COM>
Date: Fri, 28 Feb 86 17:06 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Date: Fri, 28 Feb 86 15:04 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Date: Tue, 25 Feb 86 11:15 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
reduce should have a :KEY keyword argument. For example, suppose you
have a sequence of sequences, and you want to know the sum of the
lengths of the inner sequences. Currently, I think you have to do
(reduce #'(lambda (so-far subsequence)
(+ so-far (length sub-sequence)))
sequence)
but I would prefer to do
(reduce #'+ sequence :key #'length)
(REDUCE #'+ (MAP (TYPE-OF sequence) #'length sequence))
Yours conses. Mine doesn't.
Argh. If you're worried about conses, use LOOP. Seems like everyone
else does. (This week I am of the opinion that all those :START and
:END keywords were a mistake.)
...
Did you mean:
modify-seq item sequence modifier &key start end from-end test test-not
modify-seq-if predicate sequence modifier &key start end from-end
modify-seq-if-not predicate item sequence modifier &key start end from-end
?
I see, I think. Yes, I want the -IF and -IF-NOT forms as well.
And should they all also take a :KEY argument?
I don't think so. Consider what :KEY does. It extracts a part of the
datastructure. To put it back, the implementation would have to do
something like
(setf (funcall key sequence-element)
(funcall modifier
(funcall key sequence-element)))
and SETF of FUNCALL isn't generally invertable.
Sorry; I meant the :KEY part to be used only in conjunction with the
test, not the modify part of the operation. See how tricky it is to
specify these things?
Seems to me JONL once proposed an omnibus sequence function with a name
such as MEMASSDELREMCONCQ-IF that simply took enough options to be able
to do anything you desired with a sequence.
--Guy
∂03-Mar-86 1553 DCP@ALLEGHENY.SCRC.Symbolics.COM Things to consider for CLtL'97
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 3 Mar 86 15:52:54 PST
Received: from NEPONSET.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 2091; Mon 3-Mar-86 18:37:06-EST
Date: Mon, 3 Mar 86 18:36 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: Things to consider for CLtL'97
To: Guy Steele <gls@THINK-AQUINAS.ARPA>, DCP@SCRC-QUABBIN.ARPA,
Common-Lisp@SU-AI.ARPA
In-Reply-To: <860303104332.1.GLS@GUIDO.THINK.COM>
Message-ID: <860303183633.9.DCP@NEPONSET.SCRC.Symbolics.COM>
Date: Mon, 3 Mar 86 10:43 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Date: Fri, 28 Feb 86 17:06 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Date: Fri, 28 Feb 86 15:04 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Date: Tue, 25 Feb 86 11:15 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
reduce should have a :KEY keyword argument. For example, suppose you
have a sequence of sequences, and you want to know the sum of the
lengths of the inner sequences. Currently, I think you have to do
(reduce #'(lambda (so-far subsequence)
(+ so-far (length sub-sequence)))
sequence)
but I would prefer to do
(reduce #'+ sequence :key #'length)
(REDUCE #'+ (MAP (TYPE-OF sequence) #'length sequence))
Yours conses. Mine doesn't.
Argh. If you're worried about conses, use LOOP. Seems like everyone
else does. (This week I am of the opinion that all those :START and
:END keywords were a mistake.)
If I were worried about speed, I would use LOOP. Since I wasn't, I
wanted to be pretty and still have some small spattering of efficiency.
(This month I'm trying not to use LOOP when other CL constructs are
cleanlier.)
...
Did you mean:
modify-seq item sequence modifier &key start end from-end test test-not
modify-seq-if predicate sequence modifier &key start end from-end
modify-seq-if-not predicate item sequence modifier &key start end from-end
?
I see, I think. Yes, I want the -IF and -IF-NOT forms as well.
And should they all also take a :KEY argument?
I don't think so. Consider what :KEY does. It extracts a part of the
datastructure. To put it back, the implementation would have to do
something like
(setf (funcall key sequence-element)
(funcall modifier
(funcall key sequence-element)))
and SETF of FUNCALL isn't generally invertable.
Sorry; I meant the :KEY part to be used only in conjunction with the
test, not the modify part of the operation. See how tricky it is to
specify these things?
Glorp! I see, you meant
(when (funcall predicate (funcall key seqeunce-element))
(setf <sequence-element> (funcall modifier sequence-element)))
Yeah, I guess that would be reasonable.
Seems to me JONL once proposed an omnibus sequence function with a name
such as MEMASSDELREMCONCQ-IF that simply took enough options to be able
to do anything you desired with a sequence.
:-{
∂03-Mar-86 1955 GJC@MC.LCS.MIT.EDU Things to consider for CLtL'97
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 3 Mar 86 19:55:45 PST
Date: Mon, 3 Mar 86 22:56:30 EST
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Subject: Things to consider for CLtL'97
To: gls@AQUINAS.THINK.COM, DCP@SCRC-QUABBIN.ARPA
cc: Common-Lisp@SU-AI.ARPA
In-reply-to: Msg of Mon 3 Mar 86 10:43 EST from Guy Steele <gls at THINK-AQUINAS.ARPA>
Message-ID: <[MC.LCS.MIT.EDU].837609.860303.GJC>
Loop and efficiency? Please save us! I write using the
mapping/sequence functional form and then add a compiler:optimizer
that will turn it into a call to a hand-microcoded %SEQUENCE-FROB-CASE-XXX
instruction. You cant get any more efficient than that.
∂04-Mar-86 0524 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Re: Environment Committee
Received: from CS.UCL.AC.UK by SU-AI.ARPA with TCP; 4 Mar 86 05:23:50 PST
Received: from aiva.edinburgh.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP
id a005943; 4 Mar 86 10:27 GMT
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@cs.ucl.ac.uk>
Date: Sat, 1 Mar 86 19:28:12 GMT
Message-Id: <5586.8603011928@aiva.edinburgh.ac.uk>
To: Fahlman@c.cs.cmu.edu, common-lisp@su-ai.arpa
Subject: Re: Environment Committee
Cc: aarons%svga.susx.ac.uk@cs.ucl.ac.uk, johnw%svga.susx.ac.uk@cs.ucl.ac.uk,
rhr%aiva.edinburgh.ac.uk@cs.ucl.ac.uk
> Date: Fri, 28 Feb 1986 09:37 EST
> From: "Scott E. Fahlman" <Fahlman@edu.cmu.cs.c>
> Subject: Environment Committee
>
> Initially we even wanted to leave open the question of whether the
> compiler was written in Lisp, though I don't think anyone has exercised
> the option not to do this and we may want to put that particular freedom
> to rest.
The PopLog Common Lisp compiler is written in Pop11. Incidently, this system
also exercises another of the more unusual implementation options: there is no
interpreter per se: EVAL just compiles and calls the resulting code.
PopLog, from the University of Sussex, is a mixed-language system which
includes Pop11, Prolog, and (when it's finished) Common Lisp. For anyone
who is interested, the best person to contact there is probably Aaron Sloman.
An address that might work is:
aarons%uk.ac.susx.svga@ucl-cs.arpa
-- Jeff
∂04-Mar-86 0916 lab@rochester.arpa
Received: from ROCHESTER.ARPA by SU-AI.ARPA with TCP; 4 Mar 86 09:16:15 PST
Received: from ur-seneca.rochester.arpa (ur-seneca) by ur-cayuga.rochester.arpa id AA18874 (4.12w); Tue, 4 Mar 86 12:16:15 est
Received: by ur-seneca.rochester.arpa id AA02181 (4.12w); Tue, 4 Mar 86 12:16:04 est
Message-Id: <8603041716.2181@ur-seneca.rochester.arpa>
Date: Tue, 4 Mar 86 12:16:04 est
From: Lab Manager(Brad Miller) <lab@rochester.arpa>
To: fahlman@c.cs.cmu.edu
Cc: common-lisp@su-ai.arpa
Subject: What does LOAD use for read table & package?
Date: Sun, 2 Mar 1986 00:31 EST
Message-Id: <FAHLMAN.12187397057.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Cc: common-lisp@SU-AI.ARPA
Subject: What does LOAD use for read table & package?
In-Reply-To: Msg of 1 Mar 1986 08:29-EST from George J. Carrette <GJC at MC.LCS.MIT.EDU>
You should not be so quick to say that the "-*-" shouldnt be used. It
may be ugly but experience has shown that it works very well.
....
But all of that is irrelevant to the point I was making. Let me try
again: There is no mention of "-*-" comments anywhere in the current
definition of Common Lisp. As far as Common Lisp is concerned,
everything in a comment is ignored. Any code that depends for its
correct interpretation on the "-*-" not being ignored is not portable
Common Lisp. Therefore, depending on this construct to set up packages
and the like should be avoided in code that is intended to be portable.
That's what In-Package is for.
-- Scott
I concur. -*- is fine if you want frozzbozzy things for your editor so it
need not actually 'read' lisp, but the lisp language certainly shouldn't
define it, nor depend on it.
Brad Miller
∂04-Mar-86 1829 DCP@ALLEGHENY.SCRC.Symbolics.COM What is that -*- line for, anyway?
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 4 Mar 86 18:27:01 PST
Received: from NEPONSET.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 2397; Tue 4-Mar-86 21:27:04-EST
Date: Tue, 4 Mar 86 21:26 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: What is that -*- line for, anyway?
To: Lab Manager <lab@ROCHESTER.ARPA>, fahlman@c.cs.cmu.edu
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8603041716.2181@ur-seneca.rochester.arpa>
Message-ID: <860304212622.2.DCP@NEPONSET.SCRC.Symbolics.COM>
Date: Tue, 4 Mar 86 12:16:04 est
From: Lab Manager(Brad Miller) <lab@rochester.arpa>
Subject: What does LOAD use for read table & package?
Date: Sun, 2 Mar 1986 00:31 EST
Message-Id: <FAHLMAN.12187397057.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Cc: common-lisp@SU-AI.ARPA
Subject: What does LOAD use for read table & package?
In-Reply-To: Msg of 1 Mar 1986 08:29-EST from George J. Carrette <GJC at MC.LCS.MIT.EDU>
You should not be so quick to say that the "-*-" shouldnt be used. It
may be ugly but experience has shown that it works very well.
....
But all of that is irrelevant to the point I was making. Let me try
again: There is no mention of "-*-" comments anywhere in the current
definition of Common Lisp. As far as Common Lisp is concerned,
everything in a comment is ignored. Any code that depends for its
correct interpretation on the "-*-" not being ignored is not portable
Common Lisp. Therefore, depending on this construct to set up packages
and the like should be avoided in code that is intended to be portable.
That's what In-Package is for.
I concur. -*- is fine if you want frozzbozzy things for your editor so it
need not actually 'read' lisp, but the lisp language certainly shouldn't
define it, nor depend on it.
I don't dissent, from a literal reading of CLtL, but I'll make the
following observations.
CLtL is a language specification. It does very little in the way of
program development tools or programming environment aids. For those
people that have non-Lisp-understanding text editors, they will parse
neither the -*- 'attribute line' nor the possible in-package forms. As
soon as you want your editor to be integrated into your environment
(e.g., be able to ask the question "What's the arglist of the function
the cursor is pointing at?" or "Macro expand the form after the cursor.")
you need to know various things about the 'state' of the file/buffer.
This includes things like *package*.
Hystorically, (MIT derived) Lisp Machine files have code which is in the
same package. Therefore, the -*- attribute list and an in-package form
are equivalent, but the former is a lot easier for the editor to
understand; either it is there at a known place or it isn't. The
compiler and loader and other >tools< where made to know about the
attribute list. In fact, binary files contain an attribute list which
requires minimal parsing of the binary file.
It is not 'certain' that a lisp language should not define it. If we
really specify the least common denominator, of course it won't be part
of the language, but the least common denominator isn't a powerful
language. If we attempt to define some relatively simple standards for
useful program development aids, then I think something should be
defined.
∂04-Mar-86 2017 GJC@MC.LCS.MIT.EDU What is that -*- line for, anyway?
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 4 Mar 86 20:17:39 PST
Date: Tue, 4 Mar 86 23:18:16 EST
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Subject: What is that -*- line for, anyway?
To: DCP@SCRC-QUABBIN.ARPA
cc: common-lisp@SU-AI.ARPA, lab@ROCHESTER.ARPA,
fahlman@C.CS.CMU.EDU
In-reply-to: Msg of Tue 4 Mar 86 21:26 EST from David C. Plummer <DCP at SCRC-QUABBIN.ARPA>
Message-ID: <[MC.LCS.MIT.EDU].839063.860304.GJC>
To add to what you have said historically speaking, orginally
it was easier for an editor to understand "-*-" rather than some
form such as (MODULE "name" :package "foo" :syntax "bar)
presumably because the "-*-" first showed up in the TECO implemented EMACS
editor on the PDP-10. Predating lispmachines of course (not by much,
so an ITS historian should check me on this).
Q: Who invented the file mode line in EMACS?
Q: Who decided to extend this to the file attribute line syntax on the Lispm?
Later the "-*-" syntax was extended to require/allow such things as
#||-*- mode:lisp;
package:(FOOBAR :USE (GLOBAL BAZ)
:SHADOW (CAR CDR CONS));
base:10
-*- ||#
From this it is obvious that our Mr. Lab Managers comment about "-*-"
being easier to parse "for your editor so that it need not actually
'read' lisp" is both ignorant and condescending. The stuff after the
":" must be parsed with READ.
-gjc
∂05-Mar-86 0046 cfry%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU misc questions
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 5 Mar 86 00:46:29 PST
Received: from MOSCOW-CENTRE.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 5 Mar 86 03:46-EST
Date: Wed, 5 Mar 86 03:46 EST
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
Subject: misc questions
To: common-lisp@SU-AI.ARPA
Message-ID: <860305034651.1.CFRY@MOSCOW-CENTRE.AI.MIT.EDU>
What does WITH-OPEN-FILE return?
I can't find it in CLtL.
I'd prefer that it return the value of the last form in its body.
When SYMBOL-FUNCTION is passed a symbol which refers to
a macro or special form, what does it return?
If FUNCTION is passed a definition, does it simply return it?
∂05-Mar-86 0632 DCP@ALLEGHENY.SCRC.Symbolics.COM misc questions
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 5 Mar 86 06:32:32 PST
Received: from NEPONSET.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 2500; Wed 5-Mar-86 09:32:51-EST
Date: Wed, 5 Mar 86 09:32 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: misc questions
To: Christopher Fry <cfry@OZ.AI.MIT.EDU>, common-lisp@SU-AI.ARPA
In-Reply-To: <860305034651.1.CFRY@MOSCOW-CENTRE.AI.MIT.EDU>
Message-ID: <860305093230.2.DCP@NEPONSET.SCRC.Symbolics.COM>
Date: Wed, 5 Mar 86 03:46 EST
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
What does WITH-OPEN-FILE return?
I can't find it in CLtL.
I'd prefer that it return the value of the last form in its body.
Funny it doesn't say. The 'obvious' way tocode it produces the expected
result: it returns the valueS of the last form of the implicit progn.
When SYMBOL-FUNCTION is passed a symbol which refers to
a macro or special form, what does it return?
The Silver bible says the definition 'may be an object representing a
special form or macro' but it is illegal to funcall such a beast.
If FUNCTION is passed a definition, does it simply return it?
You probably should depend on this. The only way to get such a thing is
by being constructed by a macro, which doesn't look pretty, e.g.,
`#',#'car
You should only pass function specs or lambda expressions in. I will
note that the Symbolics implementation is loose in this regard:
#'#.#'car => #<DTP-COMPILED-FUNCTION CAR 46350445>
and (#.#'car '(3 4)) => 3
∂05-Mar-86 0707 NGALL@G.BBN.COM Re: misc questions
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 5 Mar 86 07:05:21 PST
Date: 5 Mar 1986 10:05-EST
Sender: NGALL@G.BBN.COM
Subject: Re: misc questions
From: NGALL@G.BBN.COM
To: common-lisp@SU-AI.ARPA
Cc: cfry%oz@MC.LCS.MIT.EDU
Message-ID: <[G.BBN.COM] 5-Mar-86 10:05:17.NGALL>
In-Reply-To: <860305034651.1.@MOSCOW-CENTRE.AI.MIT.EDU>
Date: Wed, 5 Mar 86 03:46 EST
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
To: common-lisp@SU-AI.ARPA
Subject: misc questions
Message-ID: <860305034651.1.CFRY@MOSCOW-CENTRE.AI.MIT.EDU>
What does WITH-OPEN-FILE return?
I can't find it in CLtL.
I'd prefer that it return the value of the last form in its body.
I believe this is what most implementations do (since it is stated that
the forms of the body are an implicit PROGN). This should be
'clarified' though.
When SYMBOL-FUNCTION is passed a symbol which refers to
a macro or special form, what does it return?
There was a lot of discussion about this a few weeks ago. My
impression of the result of that discussion was that SYMBOL-FUNCTION
could return ANYTHING (including NIL) when passed a symbol that names
a macro or special form. All you can count on is that it WON'T signal
an error and it will return something. Of course, when passed a
symbol that names an actual function, you can assume that what is
returned is the function def. and that it can be applied, etc.
If FUNCTION is passed a definition, does it simply return it?
I assume by 'definition' you mean a lambda expression. When passed a
lambda expression, FUNCTION may return a closure (an actual data type
in some implementations, the original lambda (if no env. info. is
needed), a compiled-code object (if you are using POPLOG LISP :-)), or
any lisp object that is appliable or funcallable and that 'represents'
the original lambda expression and its defining env.
-- Nick
∂05-Mar-86 1104 lab@rochester.arpa What is that -*- line for, anyway?
Received: from ROCHESTER.ARPA by SU-AI.ARPA with TCP; 5 Mar 86 11:03:20 PST
Received: from ur-seneca.rochester.arpa (ur-seneca) by ur-cayuga.rochester.arpa id AA02590 (4.12w); Wed, 5 Mar 86 14:03:08 est
Received: by ur-seneca.rochester.arpa id AA04390 (4.12w); Wed, 5 Mar 86 14:02:49 est
Message-Id: <8603051902.4390@ur-seneca.rochester.arpa>
Date: Wed, 5 Mar 86 14:02:49 est
From: Lab Manager(Brad Miller) <lab@rochester.arpa>
To: GJC@MC.LCS.MIT.EDU
Cc: DCP@SCRC-QUABBIN.ARPA, common-lisp@SU-AI.ARPA, fahlman@C.CS.CMU.EDU
In-Reply-To: "George J. Carrette"'s message of Tue, 4 Mar 86 23:18:16 EST
Subject: What is that -*- line for, anyway?
Date: Tue, 4 Mar 86 23:18:16 EST
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
To add to what you have said historically speaking, orginally
it was easier for an editor to understand "-*-" rather than some
form such as (MODULE "name" :package "foo" :syntax "bar)
presumably because the "-*-" first showed up in the TECO implemented EMACS
editor on the PDP-10. Predating lispmachines of course (not by much,
so an ITS historian should check me on this).
Later the "-*-" syntax was extended to require/allow such things as
#||-*- mode:lisp;
package:(FOOBAR :USE (GLOBAL BAZ)
:SHADOW (CAR CDR CONS));
base:10
-*- ||#
>From this it is obvious that our Mr. Lab Managers comment about "-*-"
being easier to parse "for your editor so that it need not actually
'read' lisp" is both ignorant and condescending. The stuff after the
":" must be parsed with READ.
-gjc
1. Hardly ignorant nor condescending, as I was not talking about lisp
FORMS. Your editor need not read the
lisp IN THE FILE to determined the package of an expression, because
an appropriate form is on the attribute line. Furthermore, that is all
the editor is expected to know. If you change packages in the middle of
the filed, the editor is not expected to follow the switch. Nor do I
think we should expect it to, nor is this issue part of CLtL, hence my
comment.
2. On the symbolics (at least) use of the make-system construct allows
you to specify the package to compile or load a file into. It
OVERRIDES anything on the attribute line. This makes a lot of sense:
common subroutines can be loaded into my package this way, but if I
were to edit the subroutines the attribute line would have to be
overridden if I expected immediate effect on *my* programming
environment (that is, the one I had loaded it into).
Conclusion: the attribute line's idea of the package and the package a
file is compiled or loaded into are independant entities and should
remain that way. Both are environment issues, neither must be
specified by CLtL, and my opinion is that neither should be.
Brad Miller ARPA: lab@rochester.arpa UUCP:rochester!lab
(also miller@rochester for grad student stuff)
Title: CS Lab Manager
Snail: University of Rochester Computer Science Department
617 Hylan Building Rochster, NY 14627
PS: sorry for the 'lab' signature, but my 'miller' account is on a
lispm which currently does not forward to the arpa net.
∂05-Mar-86 1925 FAHLMAN@C.CS.CMU.EDU Environment Committee
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 5 Mar 86 19:22:46 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 5 Mar 86 22:22:47-EST
Date: Wed, 5 Mar 1986 22:22 EST
Message-ID: <FAHLMAN.12188422184.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@CS.UCL.AC.UK>
Cc: aarons%svga.susx.ac.uk@CS.UCL.AC.UK, common-lisp@SU-AI.ARPA,
johnw%svga.susx.ac.uk@CS.UCL.AC.UK,
rhr%aiva.edinburgh.ac.uk@CS.UCL.AC.UK
Subject: Environment Committee
In-reply-to: Msg of 1 Mar 1986 14:28-EST from Jeff Dalton <jeff%aiva.edinburgh.ac.uk at cs.ucl.ac.uk>
Is it safe to assume that when Common Lisp is being compiled by Pop11,
the system is operating as a Common Lisp superset? If not, how do you
do macros? If so, one might still argue that nobody has implemented a
Common Lisp compiler that is not in Common Lisp. The point of this is
that we might want to specify more clearly what effect various
compilation operations ahve on "the surrounding Lisp system".
-- Scott
∂06-Mar-86 0631 NETS.NRTC@USC-ECL.ARPA Scope and declare
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 6 Mar 86 06:28:47 PST
Date: Wed, 5 Mar 86 17:07:11 PST
From: Jeff Barnett <jbarnett%NRTC@USC-ECL.ARPA>
To: COMMON-LISP@SU-AI.ARPA
Subject: Scope and declare
Via: Nrtc; 06 Mar 86 05:47:20
In re CL book, page 155, example programm nonsense: why is the scope
rule as stated? Is this a firm decision? If so, why? As I understand it,
this is an inconpatible decision to virtually every other LISP that has been
written. LET and PROG binding semantics can no longer be explained in terms
of those associated with LAMBDA. Among other things, macro expansions can no
longer use binding forms as they do now.
In the rare case where the declaration should prevade the preset
expression, that expression can be wrapped with a LET and a duplicate DECLARE.
Since the inside of a macro can't tell or find out what the outside context
is, it can't do the wrapping to regain it.
∂06-Mar-86 1207 liz@brillig.umd.edu Re: loop macro
Received: from BRILLIG.UMD.EDU by SU-AI.ARPA with TCP; 6 Mar 86 12:07:01 PST
Received: by brillig.umd.edu (5.9/4.7)
id AA14513; Thu, 6 Mar 86 15:07:49 EST
Message-Id: <8603062007.AA14513@brillig.umd.edu>
To: rwk@scrc-yukon.ARPA
Cc: common-lisp@su-ai.ARPA
Subject: Re: loop macro
In-Reply-To: Your message of Thu, 13 Feb 86 13:36 EST.
<860213133639.3.RWK@CROW.SCRC.Symbolics.COM>
Date: Thu, 06 Mar 86 15:07:47 -0500
From: Liz Allen <liz@brillig.umd.edu>
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
From: Liz Allen <liz@brillig.umd.edu>
I don't really remember needing to use a DO* type
binding of iteration variables. I guess I would use
a LET to bind some common value and use it in the init
part of the iteration values.
I use the DO* type of binding far more often than not.
And it isn't an issue for the init part of the iteration,
it's for the stepping.
I finally had a chance to look up DO vs DO* in CLtL -- and I was
mistaken above. It turns out that the Franz DO that we use works
exactly like the DO* in Common Lisp... So, we always use DO* type
binding -- and have never seemed to need the other type of binding.
-Liz
∂06-Mar-86 1754 hpfclp!diamant@hplabs.ARPA get-setf-method
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 6 Mar 86 17:54:23 PST
Received: by hplabs.ARPA ; Thu, 6 Mar 86 17:54:10 pst
Date: Thu, 6 Mar 86 17:54:10 pst
From: hpfclp!diamant@hplabs.ARPA
To: common-lisp@su-ai.ARPA
Subject: get-setf-method
In the proposed clarifications for CLtL, for page 107, GLS states
that GET-SETF-METHOD should not do macroexpansion, and
that it should be called with an already expanded form.
The purpose of this change is to avoid having to make GET-SETF-METHOD
take an &environment parameter, since MACROEXPAND needs it.
He says "in most contexts the usage should be
(GET-SETF-METHOD (MACROEXPAND form env))." This seems
incorrect to me, as there may be a setf method defined on an intermediate
expansion of the macro, which should take precedence over the macroexpansion.
In order to correct this problem, each function which called GET-SETF-METHOD
would have to repeatedly call it with MACROEXPAND-1 until there were no
longer any macros to expand, or GET-SETF-METHOD found a setf method.
What would GET-SETF-METHOD return if it didn't find a setf method?
Here is an example of the problem:
(defsetf foo boat)
(defmacro foobar (x) `(foo ,x))
(defmacro foo (x) `(car ,x))
(setq x '(a . b))
(setf (foobar x) 3) ; this will expand to something equivalent to
; (setf (car x) 3) instead of calling boat as
; the update function.
In other words, it missed the boat!
In looking at the current SPICE sources, I see that GET-SETF-METHOD does
take an environment, and MACROEXPAND-1 is called repeatedly, rather than
MACROEXPAND. Due to the discrepency between the SPICE code and the
clarifications list, I assume that either no consensus has been reached,
or some decision has been made of which I am not aware.
John Diamant
Hewlett Packard Company diamant%hpfclp@hplabs.arpa
∂06-Mar-86 2059 apollo!dfm@uw-beaver.arpa initforms and implicit blocks
Received: from UW-BEAVER.ARPA by SU-AI.ARPA with TCP; 6 Mar 86 20:54:22 PST
Received: by uw-beaver.arpa (4.42/4.2)
id AA16622; Thu, 6 Mar 86 21:00:50 PST
Return-Path: <apollo!dfm@uw-beaver.arpa>
Message-Id: <8603070500.AA16622@uw-beaver.arpa>
From: apollo!dfm@uw-beaver.arpa
Date: Thu, 6 Mar 86 17:18:28 EST
Subject: initforms and implicit blocks
To: COMMON-LISP@su-ai.arpa
Apologies if this has been discussed before.
Are initforms in &optional, &key, and &aux parameters evaluated inside or
outside the implicit block provided by defun and friends? In particular,
should the following return t or nil?
(block f
(labels ((f (&optional (x (return-from f nil)))))
(f)
t) )
As near as I can tell CLtL is silent on this. Perhaps it simply "is an error"
to depend on either behavior? At first glance, it seems most tasteful to have
them evaluated within the implicit block.
- Don Morrison
∂06-Mar-86 2118 DLW@ALLEGHENY.SCRC.Symbolics.COM What is that -*- line for, anyway?
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 6 Mar 86 21:18:29 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 3054; Fri 7-Mar-86 00:18:43-EST
Date: Fri, 7 Mar 86 00:24 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: What is that -*- line for, anyway?
To: GJC@MC.LCS.MIT.EDU
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <[MC.LCS.MIT.EDU].839063.860304.GJC>
Message-ID: <860307002413.7.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Tue, 4 Mar 86 23:18:16 EST
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Q: Who invented the file mode line in EMACS?
I'm not sure whether it was Moon, Steele, or Stallman.
Q: Who decided to extend this to the file attribute line syntax on the Lispm?
I did.
However, speaking as the definer of the file attribute line, I do not
think that we should make any attempt to standardize on it. It's part
of the programming environment, not the language, and it would be a big
mistake to start slipping into the programming environment business.
Yes, one does need some kind of facility to solve the problems that the
file attribute line solves. But this should not be part of the CL
standard.
For one thing, as Miller points out, when you have make-system, you now
have an alternative method of saying things about packages of files.
The CL spec should not forbid this or interfere with it.
For another, in our next generation of software development environment
tools, the way to solve the problem will not be with a file attribute
line at all. I don't want to be stuck with the file attribute line as
part of a standard when I can already see a near future in which it is
obsolete.
∂06-Mar-86 2321 DLW@ALLEGHENY.SCRC.Symbolics.COM What is that -*- line for, anyway?
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 6 Mar 86 21:18:29 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 3054; Fri 7-Mar-86 00:18:43-EST
Date: Fri, 7 Mar 86 00:24 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: What is that -*- line for, anyway?
To: GJC@MC.LCS.MIT.EDU
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <[MC.LCS.MIT.EDU].839063.860304.GJC>
Message-ID: <860307002413.7.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Tue, 4 Mar 86 23:18:16 EST
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Q: Who invented the file mode line in EMACS?
I'm not sure whether it was Moon, Steele, or Stallman.
Q: Who decided to extend this to the file attribute line syntax on the Lispm?
I did.
However, speaking as the definer of the file attribute line, I do not
think that we should make any attempt to standardize on it. It's part
of the programming environment, not the language, and it would be a big
mistake to start slipping into the programming environment business.
Yes, one does need some kind of facility to solve the problems that the
file attribute line solves. But this should not be part of the CL
standard.
For one thing, as Miller points out, when you have make-system, you now
have an alternative method of saying things about packages of files.
The CL spec should not forbid this or interfere with it.
For another, in our next generation of software development environment
tools, the way to solve the problem will not be with a file attribute
line at all. I don't want to be stuck with the file attribute line as
part of a standard when I can already see a near future in which it is
obsolete.
∂06-Mar-86 2321 apollo!dfm@uw-beaver.arpa initforms and implicit blocks
Received: from UW-BEAVER.ARPA by SU-AI.ARPA with TCP; 6 Mar 86 20:54:22 PST
Received: by uw-beaver.arpa (4.42/4.2)
id AA16622; Thu, 6 Mar 86 21:00:50 PST
Return-Path: <apollo!dfm@uw-beaver.arpa>
Message-Id: <8603070500.AA16622@uw-beaver.arpa>
From: apollo!dfm@uw-beaver.arpa
Date: Thu, 6 Mar 86 17:18:28 EST
Subject: initforms and implicit blocks
To: COMMON-LISP@su-ai.arpa
Apologies if this has been discussed before.
Are initforms in &optional, &key, and &aux parameters evaluated inside or
outside the implicit block provided by defun and friends? In particular,
should the following return t or nil?
(block f
(labels ((f (&optional (x (return-from f nil)))))
(f)
t) )
As near as I can tell CLtL is silent on this. Perhaps it simply "is an error"
to depend on either behavior? At first glance, it seems most tasteful to have
them evaluated within the implicit block.
- Don Morrison
∂06-Mar-86 2334 RAM@C.CS.CMU.EDU initforms and implicit blocks
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 6 Mar 86 23:28:22 PST
Received: ID <RAM@C.CS.CMU.EDU>; Fri 7 Mar 86 01:59:11-EST
Date: Fri, 7 Mar 1986 01:28 EST
Message-ID: <RAM.12188718202.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: apollo!dfm@UW-BEAVER.ARPA
Cc: COMMON-LISP@SU-AI.ARPA
Subject: initforms and implicit blocks
In-reply-to: Msg of Thu 6 Mar 86 17:18:28 EST from apollo!dfm at uw-beaver.arpa
Date: Thu, 6 Mar 86 17:18:28 EST
From: apollo!dfm at uw-beaver.arpa
Re: initforms and implicit blocks
Are initforms in &optional, &key, and &aux parameters evaluated
inside or outside the implicit block provided by defun and
friends? ... At first glance, it seems most tasteful to have them
evaluated within the implicit block.
What could DEFUN expand into which would place the arguments within
the scope of the block? The obvious expansion of DEFUN is something
like:
(setf (symbol-function '<name>) #'(lambda <arglist> (block <name> <body>))
Rob
∂07-Mar-86 0625 DCP@ALLEGHENY.SCRC.Symbolics.COM get-setf-method
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 7 Mar 86 06:25:36 PST
Received: from NEPONSET.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 3109; Fri 7-Mar-86 09:25:57-EST
Date: Fri, 7 Mar 86 09:25 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: get-setf-method
To: hpfclp!diamant@HPLABS.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: The message of 6 Mar 86 20:54-EST from hpfclp!diamant@hplabs.ARPA
Message-ID: <860307092548.2.DCP@NEPONSET.SCRC.Symbolics.COM>
FYI, I'm pretty sure we already convinced GLS that get-setf-methods MUST
NOT be passed an already macro-expanded form, which implies it must get
an environment so it can do its own macroexpansions, as you notice the
SPICE code does.
Maybe we need an up-to-date list of proposed changes which incorporates
the discussions generated by the last list?
∂07-Mar-86 0659 greek%bach.decnet@hudson.dec.com The ~C format directive
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 7 Mar 86 06:59:09 PST
Date: 0 0 00:00:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: The ~C format directive
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Does anyone have a guess as to what the ~C format directive (without any
modifiers) is supposed to do? CLtL says "prints the character in an
implementation-dependent abbreviated format."
At least one person has said they think it should just throw the
character at the terminal, as with ~A.
Currently, VAX LISP prints it like ~S would, abbreviating any control
bits down to one letter. This seems right according to the rationale
given under the description of ~C. But then one can't use any variant
of ~C to just throw the character at the terminal.
Any opinions?
- Paul
------
∂07-Mar-86 0659 greek%bach.decnet@hudson.dec.com List of Changes
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 7 Mar 86 06:59:25 PST
Date: 0 0 00:00:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: List of Changes
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
I second the motion for an up-to-date list of proposed changes. In fact,
a complete list of every single proposed changed to CLtl, even typos
and nits, would be great.
- Paul
------
∂07-Mar-86 0727 gls@THINK-AQUINAS.ARPA What is that -*- line for, anyway?
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 7 Mar 86 07:27:09 PST
Received: from nymphodora by GODOT.THINK.COM via CHAOS; Fri, 7 Mar 86 10:27:41 est
Date: Fri, 7 Mar 86 10:29 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: What is that -*- line for, anyway?
To: DLW@SCRC-QUABBIN.ARPA, GJC@MC.LCS.MIT.EDU
Cc: common-lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA
In-Reply-To: <860307002413.7.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-Id: <860307102943.1.GLS@THINK-NYMPHODORA.ARPA>
Date: Fri, 7 Mar 86 00:24 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Date: Tue, 4 Mar 86 23:18:16 EST
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Q: Who invented the file mode line in EMACS?
I'm not sure whether it was Moon, Steele, or Stallman.
Not me. Probably Stallman. --Guy
∂07-Mar-86 0731 gls@THINK-AQUINAS.ARPA get-setf-method
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 7 Mar 86 07:30:10 PST
Received: from nymphodora by GODOT.THINK.COM via CHAOS; Fri, 7 Mar 86 10:30:42 est
Date: Fri, 7 Mar 86 10:32 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: get-setf-method
To: DCP@SCRC-QUABBIN.ARPA, hpfclp!diamant@HPLABS.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <860307092548.2.DCP@NEPONSET.SCRC.Symbolics.COM>
Message-Id: <860307103246.2.GLS@THINK-NYMPHODORA.ARPA>
Date: Fri, 7 Mar 86 09:25 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
FYI, I'm pretty sure we already convinced GLS that get-setf-methods MUST
NOT be passed an already macro-expanded form, which implies it must get
an environment so it can do its own macroexpansions, as you notice the
SPICE code does. ...
That is correct. I was wedged. GET-SETF-METHODS must take an environment
argument.
--Guy
∂07-Mar-86 0734 NGALL@G.BBN.COM Re: initforms and implicit blocks
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 7 Mar 86 07:34:29 PST
Date: 7 Mar 1986 10:32-EST
Sender: NGALL@G.BBN.COM
Subject: Re: initforms and implicit blocks
From: NGALL@G.BBN.COM
To: apollo!dfm@UW-BEAVER.ARPA
Cc: COMMON-LISP@SU-AI.ARPA
Message-ID: <[G.BBN.COM] 7-Mar-86 10:32:17.NGALL>
In-Reply-To: <8603070500.AA16622@uw-beaver.arpa>
Date: Thu, 6 Mar 86 17:18:28 EST
From: apollo!dfm@uw-beaver.arpa
To: COMMON-LISP@su-ai.arpa
Subject: initforms and implicit blocks
Message-ID: <8603070500.AA16622@uw-beaver.arpa>
Apologies if this has been discussed before.
Are initforms in &optional, &key, and &aux parameters evaluated inside or
outside the implicit block provided by defun and friends? In particular,
should the following return t or nil?
(block f
(labels ((f (&optional (x (return-from f nil)))))
(f)
t) )
As near as I can tell CLtL is silent on this. Perhaps it simply "is an error"
to depend on either behavior? At first glance, it seems most tasteful to have
them evaluated within the implicit block.
- Don Morrison
--------------------
On pg 67:
"The FORMS constitute the body of the defined function..."
"The body of the defined function is implicitly enclosed in a BLOCK
construct..."
I think this strongly implies that the init forms are not enclosed by the
BLOCK, since they are not part of the body by this definition. Since this
definition of body is somewhat at odds with the definition of body used
in the DECL. chapter (pg 155), the fact that init forms are not
enclosed in the block should be made explicit.
Of course, I would prefer that init forms were considered part of the
body in all contexts (hence one could do returns in them), but I think
most implementations have already done it the easy way.
-- Nick
∂07-Mar-86 0742 NGALL@G.BBN.COM Re: The ~C format directive
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 7 Mar 86 07:42:05 PST
Date: 7 Mar 1986 10:40-EST
Sender: NGALL@G.BBN.COM
Subject: Re: The ~C format directive
From: NGALL@G.BBN.COM
To: greek%bach.decnet@HUDSON.DEC.COM
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM] 7-Mar-86 10:40:21.NGALL>
In-Reply-To: The message of 0 0 00:00:00 EST from "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: The ~C format directive
Does anyone have a guess as to what the ~C format directive (without any
modifiers) is supposed to do? CLtL says "prints the character in an
implementation-dependent abbreviated format."
At least one person has said they think it should just throw the
character at the terminal, as with ~A.
I agree.
Currently, VAX LISP prints it like ~S would, abbreviating any control
bits down to one letter. This seems right according to the rationale
given under the description of ~C. But then one can't use any variant
of ~C to just throw the character at the terminal.
~@C should be used to print a char. in a readable way (i.e. "like ~S
would").
Any opinions?
- Paul
------
-- Nick
∂07-Mar-86 1004 JAR@MC.LCS.MIT.EDU Need for (declare (ignorable ...))
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 7 Mar 86 10:04:25 PST
Date: Fri, 7 Mar 86 13:05:09 EST
From: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
Subject: Need for (declare (ignorable ...))
To: common-lisp@SU-AI.ARPA
Message-ID: <[MC.LCS.MIT.EDU].842283.860307.JAR>
Common Lisp (and in fact, every language that has variables) needs a
(DECLARE (IGNORABLE ...)) in addition to (DECLARE (IGNORE ...)). The
meaning of (DECLARE (IGNORABLE X)) is: the variable X might or might not
be used, and I don't want the compiler to generate a warning in either
case.
There is no way to simulate this feature in Common Lisp. If there is no
such declaration, and X isn't used, then I get a warning message X bound
but not used; if I use (DECLARE (IGNORE X)), and X is used, then I get a
warning message saying that X was declared ignored but in fact was used.
I wouldn't want to change either of these features of Common Lisp
compilers.
The IGNORABLE declaration is needed for applications where code is
automatically generated, say, by a macro or a compiler. A macro,
especially, is not in a good position to know whether a variable is
being referenced. A sledgehammer like a code traversal tool shouldn't
be required for this simple application. It has been in T (Yale Scheme)
since 1981, and has proved very useful.
Have other people suffered from this lack, or do I just write
particularly perverse macros?
Jonathan Rees
∂07-Mar-86 1020 greek%bach.decnet@hudson.dec.com IGNORABLE.
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 7 Mar 86 10:20:17 PST
Date: 0 0 00:00:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: IGNORABLE.
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Silly software!
A DECLARE IGNORABLE would indeed be quite useful. I don't think
Jonathan writes particularly perverse macros.
- Paul
------
∂07-Mar-86 1038 DCP@ALLEGHENY.SCRC.Symbolics.COM Need for (declare (ignorable ...))
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 7 Mar 86 10:33:23 PST
Received: from NEPONSET.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 3184; Fri 7-Mar-86 13:33:39-EST
Date: Fri, 7 Mar 86 13:33 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: Need for (declare (ignorable ...))
To: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>, common-lisp@SU-AI.ARPA
In-Reply-To: <[MC.LCS.MIT.EDU].842283.860307.JAR>
Message-ID: <860307133328.6.DCP@NEPONSET.SCRC.Symbolics.COM>
Date: Fri, 7 Mar 86 13:05:09 EST
From: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
Common Lisp (and in fact, every language that has variables) needs a
(DECLARE (IGNORABLE ...)) in addition to (DECLARE (IGNORE ...)). The
meaning of (DECLARE (IGNORABLE X)) is: the variable X might or might not
be used, and I don't want the compiler to generate a warning in either
case.
I agree.
There is no way to simulate this feature in Common Lisp. If there is no
such declaration, and X isn't used, then I get a warning message X bound
but not used; if I use (DECLARE (IGNORE X)), and X is used, then I get a
warning message saying that X was declared ignored but in fact was used.
I wouldn't want to change either of these features of Common Lisp
compilers.
(defun foo (x)
x
'bar)
Is one possible workaround, but it doesn't make it obvious what the
intent is. In Symbolics Common Lisp, you can do
(defun foo (x)
(ignore x)
'bar)
which is a common cliche because the IGNORABLE declaration doesn't
exist.
The IGNORABLE declaration is needed for applications where code is
automatically generated, say, by a macro or a compiler. A macro,
especially, is not in a good position to know whether a variable is
being referenced. A sledgehammer like a code traversal tool shouldn't
be required for this simple application. It has been in T (Yale Scheme)
since 1981, and has proved very useful.
Have other people suffered from this lack, or do I just write
particularly perverse macros?
Jonathan Rees
∂07-Mar-86 1043 WHOLEY@C.CS.CMU.EDU Need for (declare (ignorable ...))
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 7 Mar 86 10:40:28 PST
Received: ID <WHOLEY@C.CS.CMU.EDU>; Fri 7 Mar 86 13:40:51-EST
Date: Fri, 7 Mar 1986 13:40 EST
Message-ID: <WHOLEY.12188851452.BABYL@C.CS.CMU.EDU>
Sender: WHOLEY@C.CS.CMU.EDU
From: Skef Wholey <Wholey@C.CS.CMU.EDU>
To: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
Cc: common-lisp@SU-AI.ARPA
Subject: Need for (declare (ignorable ...))
In-reply-to: Msg of 7 Mar 1986 13:05-EST from Jonathan A Rees <JAR at MC.LCS.MIT.EDU>
Date: Friday, 7 March 1986 13:05-EST
From: Jonathan A Rees <JAR at MC.LCS.MIT.EDU>
Re: Need for (declare (ignorable ...))
Common Lisp (and in fact, every language that has variables) needs a
(DECLARE (IGNORABLE ...)) in addition to (DECLARE (IGNORE ...)). The
meaning of (DECLARE (IGNORABLE X)) is: the variable X might or might not
be used, and I don't want the compiler to generate a warning in either
case.
...
Have other people suffered from this lack, or do I just write
particularly perverse macros?
I think the problem is widespread enough to warrant something with the effect
of that declaration. A change like this will probably take years to become
"real Common Lisp," but there are other ways around this.
One writer of system code in the Spice Lisp system ran into this problem, and
just added references to the "ignorable" variables right after their binding.
When we switched to a new compiler, which was smarter in a number of ways,
warnings were generated because the referenced-p slot of the variable's
compiler data structure wasn't set when the variable reference could be
optimized away. By lobbying hard, I was able to convince the compiler writer
(Scott Fahlman), that the right thing to do IS to count that reference, since
dummy references are the only way to supress warnings in such cases, AND
since optimization is the compiler's business, references should be counted as
they are written, not as they appear in code. For instance, generating a
warning that an index variable is not referenced after the compiler has
unrolled a loop would be truly asinine.
So, I would suggest that Common Lisp compilers treat all references equally in
this respect, even though some may be optimized away. Then writers of hairy
macros can insert references to these variables and be sure of getting only
valid warnings.
Side note: Most "portable" Common Lisp code I've had to deal with generates all
kinds of warnings when compiled. It's not clear if this is because different
implementations warn about different things or if the code needs ignore
declarations, or whatever, but it would be nice if people would try to make
such code compile without warnings before inviting other people to use it.
--Skef
∂07-Mar-86 1112 KMP@SCRC-STONY-BROOK.ARPA IGNORABLE
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 7 Mar 86 11:11:22 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 432906; Fri 7-Mar-86 13:57:04-EST
Date: Fri, 7 Mar 86 13:57 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: IGNORABLE
To: JAR@MIT-MC.ARPA
cc: Common-Lisp@SU-AI.ARPA
Message-ID: <860307135721.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Fri, 7 Mar 86 13:05:09 EST
From: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
Common Lisp (and in fact, every language that has variables) needs a
(DECLARE (IGNORABLE ...)) in addition to (DECLARE (IGNORE ...)). The
meaning of (DECLARE (IGNORABLE X)) is: the variable X might or might not
be used, and I don't want the compiler to generate a warning in either
case.
There is no way to simulate this feature in Common Lisp. ...
While I agree that (DECLARE (IGNORABLE ...)) would be nice.
I dispute your contention that you can't simulate this feature. I always just write:
(DEFMACRO WITH-FOO (&BODY BODY)
`(LET ((FOO (COMPUTE-FOO)))
FOO ;ignorable
,@(OR BODY '(NIL))))
I've never seen a reasonable Lisp compiler that didn't handle this correctly.
I would even argue that it is indirectly implied by the language specification
that this must work, and that it's a bug if a compiler warns either about
no FOO in body or a FOO in body.
-kmp
ps Please no discussion about what happens if BODY begins with a DECLARE form.
The example above is obviously oversimplified in that respect, but adequate
discussion of that issue has already taken place and isn't relevant here.
∂07-Mar-86 1200 franz!fimass!jkf@kim.berkeley.edu Re: Need for (declare (ignorable ...))
Received: from KIM.BERKELEY.EDU by SU-AI.ARPA with TCP; 7 Mar 86 11:52:51 PST
Received: by kim.berkeley.edu (5.45/1.8)
id AA02587; Fri, 7 Mar 86 11:51:53 PST
Received: from fimass by franz (5.5/3.14)
id AA08800; Fri, 7 Mar 86 11:26:23 PST
Received: by fimass (5.5/3.14)
id AA01640; Fri, 7 Mar 86 10:23:07 PST
Date: Fri, 7 Mar 86 10:23:07 PST
From: franz!fimass!jkf@kim.berkeley.edu (John Foderaro)
Return-Path: <fimass!jkf>
Message-Id: <8603071823.AA01640@fimass>
To: jar@mit.lcs.mit.edu
Subject: Re: Need for (declare (ignorable ...))
Cc: common-lisp@su-ai.arpa
In-Reply-To: Your message of Fri, 7 Mar 86 13:05:09 EST
We also found such a declaration to be necessary and added it to our
common lisp. However, the name is 'ignore-if-unused', not 'ignorable'.
john foderaro
∂07-Mar-86 1206 DCP@ALLEGHENY.SCRC.Symbolics.COM Need for (declare (ignorable ...))
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 7 Mar 86 11:55:04 PST
Received: from NEPONSET.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 3218; Fri 7-Mar-86 14:55:16-EST
Date: Fri, 7 Mar 86 14:55 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: Need for (declare (ignorable ...))
To: Skef Wholey <Wholey@C.CS.CMU.EDU>,
Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <WHOLEY.12188851452.BABYL@C.CS.CMU.EDU>
Message-ID: <860307145510.0.DCP@NEPONSET.SCRC.Symbolics.COM>
Suppose a rather smart compiler that knows if things are being evaluated
for effect or for value, and if functions are meant to be called for
effect or for value. It would be rather natural for such a compiler to
warn if you are using something for effect which has absolutely no side
effects. A reference to a variable, as in
(defun foo (x)
x
'bar)
could be considered 'an error in semantics' and the compiler might be
justified in producing a warning.
Likewise
(defun foo (x)
(cons x x)
'bar)
could be considered an error. Granted, it side effects the consing
system, the storage system, the paging system and the GC, but those are
supposed to be invisible to Lisp.
I'm not saying free references to variables should produce these
warnings. Because we don't currently have an IGNORABLE declaration, it
probably shouldn't. If and when we do, I personally would probably lean
toward encouraging compilers to issue warnings under these
circumstances.
∂08-Mar-86 1216 preece%ccvaxa@gswd-vms Re: IGNORABLE.
Received: from GSWD-VMS.ARPA by SU-AI.ARPA with TCP; 8 Mar 86 12:16:26 PST
Received: from ccvaxa.GSD (ccvaxa.ARPA) by gswd-vms.ARPA (5.9/)
id AA02896; Fri, 7 Mar 86 15:42:59 CST
Message-Id: <8603072142.AA02896@gswd-vms.ARPA>
Date: Fri, 7 Mar 86 15:42:14 cst
From: preece%ccvaxa@gswd-vms (Scott E. Preece)
To: COMMON-LISP@su-ai.arpa
Subject: Re: IGNORABLE.
I vote for (declare (ignore-if-unsused ...)) as more
specific than (declare (ignorable ...)). Please let's
make one of them part of the standard.
∂08-Mar-86 1439 greek%bach.decnet@hudson.dec.com IGNORE and friends.
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 8 Mar 86 14:39:02 PST
Date: 0 0 00:00:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: IGNORE and friends.
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
I think "ignore" means "I, the programmer, am going to ignore this
variable". Therefore the compiler has the right to complain if in fact
you didn't ignore it, but used it.
If you buy that, then "ignore-if-unused" isn't in the right person,
since it means "please, compiler, ignore this if I don't use it." Note
the inconsistency in person.
Thus I propose "maybe-ignore", which means "I, the programmer, may
ignore this variable, or I may not."
Now if you think that "ignore" really means "please ignore this
variable, Mr. compiler" then the compiler has no right to complain one
way or the other about the variable, since you told it to ignore the
variable.
Critical stuff.
- Paul
------
∂09-Mar-86 1140 shebs%utah-orion@utah-cs.arpa Re: ignorable
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 9 Mar 86 11:40:28 PST
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA03193; Sun, 9 Mar 86 12:42:46 MST
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA20539; Sun, 9 Mar 86 12:42:43 MST
Date: Sun, 9 Mar 86 12:42:43 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8603091942.AA20539@utah-orion.ARPA>
To: common-lisp@su-ai.arpa
Subject: Re: ignorable
I don't understand why everyone is getting so excited about a declaration
of IGNORABLE for variables. So far as I can tell, its sole purpose in life
is to suppress some compiler warnings - it has no effect on either the
performance or correctness of code. But IGNORABLE opens up a whole can
of worms - what about all the other kinds of warnings that people's compilers
might want to issue? How about a (PROCLAIM 'CONSTANTS-MIGHT-BE-REBOUND)?
Or (PROCLAIM 'TYPE-ERRORS-NO-PROBLEM)? Trying to ensure that your program
will go on all compilers in the world without any warnings whatsoever is
probably a lost cause. The only way I know of to get this degree of
portability is to use exactly the same implementation code on all machines
a la PSL...
I'm not saying that IGNORABLE is bad - I just don't think it's worth
writing into an already huge language standard, and if *that* gets in,
everybody who has a desirable but sometimes annoying warning message
in their implementation is going to want to include a control frob
in the standard. (Remember UNSPECIAL, and the discussion about general
undos that it precipitated? Does anybody still want to incorporate
a general UNDO in CL?) For instance, PSL has a warning about strings
that go over the end of the line, and it warns about users redefining
"system" functions, and it puts out a message everytime a function is
redefined, and it warns about attempts to redefine constants, and...
Every one of these is ideally controlled by its very own declaration!
stan
∂09-Mar-86 1434 SOLEY@MC.LCS.MIT.EDU IGNORABLE.
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 9 Mar 86 14:33:45 PST
Date: Sun, 9 Mar 86 17:34:31 EST
From: Richard Mark Soley <SOLEY@MC.LCS.MIT.EDU>
Subject: IGNORABLE.
To: preece%ccvaxa@GSWD-VMS.ARPA
cc: COMMON-LISP@SU-AI.ARPA
In-reply-to: Msg of Fri 7 Mar 86 15:42:14 cst from preece%ccvaxa at gswd-vms (Scott E. Preece)
Message-ID: <[MC.LCS.MIT.EDU].844192.860309.SOLEY>
Date: Fri, 7 Mar 86 15:42:14 cst
From: preece%ccvaxa at gswd-vms (Scott E. Preece)
I vote for (declare (ignore-if-unsused ...)) as more specific than
(declare (ignorable ...)).
I agree we need some feature like this. However, this "declare
ignore" stuff is really nonsense -- what we're talking about is
*suppressing warning messages*, not something akin to "declare
special."
How about a general approach, like
(supress-compiler-warnings (unused-variable x y z)
(undefined-function glorp)
. . .)
Put it inside DECLARE, if you want.
-- Richard
∂09-Mar-86 1540 KMP@SCRC-STONY-BROOK.ARPA TRUE, FALSE
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 9 Mar 86 15:40:29 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 433716; Sun 9-Mar-86 18:39:32-EST
Date: Sun, 9 Mar 86 18:40 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: TRUE, FALSE
To: Common-Lisp@SU-AI.ARPA
Message-ID: <860309184010.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
For the next edition, could we introduce functions TRUE and FALSE which
have these definitions:
TRUE &rest ignored-arguments [Function]
Returns true (ie, the symbol T).
FALSE &rest ignored-arguments [Function]
Returns false (ie, the symbol NIL).
There are places in the error proposal that I'm about to send out to
CL-ERROR-HANDLING which have to use #'(LAMBDA (IGNORE) T) or similar
silliness to get around the fact that #'TRUE and #'FALSE don't exist.
Since these are not something that should go into the error handling
chapter, I'm reluctant to include them directly in that proposal.
By the way, I've observed these to be functions that people write a lot
anyway. Unfortunately, some people/implementations write them with one
argument and some with zero; in my experience, very few people have had
the forethought to generalize their variants to be nary functions. So,
when other applications come along later that want to use them with a
different number of arguments, they can't always do so. Having them built
into the language would help reduce this incident rate of this problem.
∂09-Mar-86 1548 KMP@SCRC-STONY-BROOK.ARPA Can, could, may, might, must, ...
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 9 Mar 86 15:48:44 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 433720; Sun 9-Mar-86 18:47:45-EST
Date: Sun, 9 Mar 86 18:48 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Can, could, may, might, must, ...
To: Common-Lisp@SU-AI.ARPA
Message-ID: <860309184822.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
The manual seems to take no stand on what should -not- be in the LISP package.
It says that the things in the book should be, but it does not say, for example,
whether it's appropriate to have the LISP package use the SYSTEM package. Could
we get people to agree that this should be discouraged, explicitly in the next
edition of the manual and socially until then?
The main reason is that this makes porting between dialects a pain. Suppose
that some implementation has a symbol SYSTEM:FOO which is a system constant.
CLtL does not prohibit that symbol being placed on the LISP package. But if
I build and application which builds a package on LISP, I have no assurance
that doing (DEFVAR FOO 3) will not be trying to redefine a system constant.
It forces you to shadow a different set of symbols on in virtually every
implementation that you want to port to, which seems counter to our goals
in creating CL in the first place.
I suggest that it be made explicitly appropriate that the USER package could
inherit from the SYSTEM package, so that functions like SYSTEM:LOGIN,
SYSTEM:HELP, SYSTEM:SUSPEND, and so on could be made available to users in
the default start-up environment without infecting portable code modules that
want to start out in a sterile environment.
∂09-Mar-86 1557 KMP@SCRC-STONY-BROOK.ARPA (LOAD ... :VERBOSE T)
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 9 Mar 86 15:57:55 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 433729; Sun 9-Mar-86 18:56:49-EST
Date: Sun, 9 Mar 86 18:57 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: (LOAD ... :VERBOSE T)
To: Common-Lisp@SU-AI.ARPA
Message-ID: <860309185727.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Can we get some clarification about what is meant by :VERBOSE T to LOAD?
There is verbose and then there's VERBOSE. Without specifying exactly
what is typed out, we should give guidelines about what kinds of things
should or could be typed out. In particular, some implementations seem
to do:
(LOAD "foo" :VERBOSE T)
Loading "foo" ... done.
while others do:
(LOAD "foo" :VERBOSE T)
Started loading the file "foo"
Variable *JOE*
Variable *MARY*
Variable *SPOT*
Function RUN
Function PLAY
Function WORK
Done loading the file "foo"
I certainly don't mind an implementation providing a way to get the
latter information, since it's sometimes quite useful. I do, however,
mind having the :VERBOSE keyword be the way to turn that information on
because it forces me to do the following:
#-OVERLY-VERBOSE (LOAD FILE :VERBOSE T)
#+OVERLY-VERBOSE (LET ((PATH (PROBEF FILE)))
(FORMAT T "~&Loading ~A ..." PATH)
(LOAD PATH :VERBOSE NIL)
(FORMAT T " done.~%"))
I presume the reason that we provided :VERBOSE in the first place was to
be able to provide a portable way to get around writing standard idioms
like this.
∂09-Mar-86 1614 KMP@SCRC-STONY-BROOK.ARPA Not just ~C, but ~A
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 9 Mar 86 16:14:04 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 433738; Sun 9-Mar-86 19:13:08-EST
Date: Sun, 9 Mar 86 19:13 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Not just ~C, but ~A
To: Common-Lisp@SU-AI.ARPA
Message-ID: <860309191344.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
This note is intended to amplify the remarks made by greek@hudson the other
day about ~C.
In VAXLISP, (FORMAT NIL "~C" #\Space) => "Space".
In Zetalisp, (FORMAT NIL "~C" #\Space) => " ".
Since the manual allows implementations to do what they want, neither of
these can easily be claimed to be a simple bug.
Worse, however, is that none of the description of ~A, PRINC, or
*PRINT-ESCAPE* give me the sense of confidence that (FORMAT NIL "~A" #\Space)
will come out with " " rather than "Space" or "#Space" since they all
talk about doing like PRIN1 but without escape characters.
Since neither ~C nor ~A seems to specify for sure that it will output #\Space
as a space, the bottom line seems to be that CL does not specify a format op
(other than ~Q) which can reliably do the job! This is a sad situation indeed.
I hope we can promptly clarify the behaviors of ~A and ~C in this regard.
At the same time, it would be good if any clarifications discussed what should
happen for characters which are not STRING-CHAR-P. I'd be content to see a
variety of things happen in this situation, but I'd like us to take some
firmer stand if we could agree to. However, if we couldn't come to an agreement
on that, it certainly shouldn't keep us from fixing the problem for the common
case of things that are STRING-CHAR-P.
∂09-Mar-86 1639 greek%bach.decnet@hudson.dec.com What's in the standard packages?
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 9 Mar 86 16:39:05 PST
Date: 0 0 00:00:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: What's in the standard packages?
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Silly mailer software.
I agree with Kent that we should specify more exactly what's in the
standard packages. Here, I think, are the issues:
1. The LISP package should have external symbols which exactly are the
Common LISP standard.
2. Either the SYSTEM package or some implementation-specific package
should contain any implementation extensions to Common LISP. Might
as well make this the SYSTEM package.
3. The USER package should use both the LISP and SYSTEM packages.
4. What should MAKE-PACKAGE use by default? Clearly the LISP package.
Probably not the SYSTEM package, although this would result in an
incompatible change for any implementation that currently puts all
public symbols in the LISP package. Such is life.
- Paul
------
∂09-Mar-86 1639 KMP@SCRC-STONY-BROOK.ARPA *FEATURES*
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 9 Mar 86 16:39:25 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 433748; Sun 9-Mar-86 19:38:21-EST
Date: Sun, 9 Mar 86 19:38 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: *FEATURES*
To: Common-Lisp@SU-AI.ARPA
Message-ID: <860309193858.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
It would be nice if every company which makes a Common-Lisp would be kind enough
to put some symbol on *FEATURES* which is the trademarked name of its company.
It would seem an obvious enough request, but I've discovered at least one
company that didn't do this; it had features for things like operating system,
machine type, Common Lisp, etc. but there could be instances of more than one
dialect of CL running under the same machine type, operating system, etc if they
were supplied by different vendors. For the sake of hacking non-portable sections
of code, it would be nice if by convention all implementors could be convinced to
do this -- and a later edition of CLtL would remind them of such.
eg, #+SYMBOLICS works in any of our implementations. If other vendors each make
sure their company's name is on their *FEATURES* list, it could save people the
hassle of doing something silly, obscure, and unreliable like:
(WHEN (FBOUNDP 'SYSTEM::FROB-SOMETHING-SOMEHOW)
;; Surely only the ACME computer company ever uses such a function name
(PUSH 'ACME *FEATURES*))
I guess it should go without saying but since nothing seems to I'll say it anyway --
vendors who provide layered products should not, in general, add their names to
the *FEATURES* list or the whole thing would end up meaningless. That is, if
DEC decided to write an editor which ran on a 3600, they might add a feature
to *FEATURES* on the 3600, but would not add the feature DEC. I say "in general"
because in a few rare cases it might be useful to commit an outright lie (in
a well-documented fashion, of course) -- cross compilation is one situation
where that issue might come up.
All suggestions above refer only to what should go in the CL implementor's
guide (I forget the relevant page color), and not necessarily to what, if
anything, should go in the CL language spec itself.
∂09-Mar-86 1719 greek%bach.decnet@hudson.dec.com Putting the company name in the *FEATURES* list.
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 9 Mar 86 17:19:05 PST
Date: 0 0 00:00:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: Putting the company name in the *FEATURES* list.
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
We at Digital didn't put our name in the *FEATURES* list, although I'm
not sure why. We did put VAX, COMMON, and VMS or ULTRIX in, I think.
Hell, the community can't even agree that COMMON ought to go in for
Common LISP.
I guess I agree that it would be useful. However, some of the #+ and #-
expressions are going to be frightening. I pity the poor developer who
has to worry about all these differences.
I also think this is all semi-useless without an official registrar for
company names, dialect names, operating system names, machine names,
etc. Different people are going to assume different spellings and
abbreviations for the same entity. A few companies even have the same
acronym.
Shall we add DEC, DIGITAL, or DIGITAL-EQUIPMENT-CORPORATION to the
*FEATURES* list?
If you'll remember, I offered to be the Common LISP registrar about six
months ago. That went over like a lead balloon.
- Paul
------
∂09-Mar-86 1723 GRISS%HP-HULK@hplabs.ARPA TRUE and FALSE as n-ary functions
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 9 Mar 86 17:22:54 PST
Received: from HP-HULK by hplabs.ARPA ; Sun, 9 Mar 86 17:23:03 pst
Date: Sun 9 Mar 86 17:22:44-PST
From: Martin <GRISS%HP-HULK@hplabs.ARPA>
Subject: TRUE and FALSE as n-ary functions
To: common-lisp%su-ai@HPLABS
Cc: GRISS%HP-HULK@HPLABS
I am in favor of Kents proposal to add TRUE and FALSE as predefined
n-ary functions.
M
-------
∂10-Mar-86 0056 RAM@C.CS.CMU.EDU which package...
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 10 Mar 86 00:54:10 PST
Received: ID <RAM@C.CS.CMU.EDU>; Mon 10 Mar 86 03:27:52-EST
Date: Mon, 10 Mar 1986 03:27 EST
Message-ID: <RAM.12189526296.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: which package...
The Spice Lisp packaging rules are someething like this:
LISP
Anything which is:
1] Defined in the manual.
2] Needed to support something in the manual, e.g. debugger
commands.
3] A potentially portable language extension, e.g. MULTIPLE-VALUE-SETF.
4] User interface commands which should always be availble,
e.g. QUIT and SAVE-ALL-BUFFERS.
SYSTEM
Random implementation constants and system interface facilities.
The idea is that all symbols which are needed for writing portable
programs are available from the LISP package. Packages only use type
SYSTEM package if they are doing system hacking. The only
reservation I have about this scheme is with the "portable extensions"
being exported from the LISP package. It would probably be a good
idea to put them somewhere else.
It seems that the big discrepancy between what we are doing and what
other people advocate has to do with the SYSTEM package. There seem
to be two interpretations of what the SYSTEM package is for:
1] The system package provides facilities needed for systems
programming. (Spice Lisp)
2] The system package provides system dependent user interface
facilities. (Greek, KMP)
In the first case, random users clearly don't want to use the SYSTEM
package. In the second case, they definitely do. I would argue that
if the system package has facilities which you always want to be
there, then it should be in the default use list.
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: What's in the standard packages?
1. The LISP package should have external symbols which exactly are the
Common LISP standard.
Symbols not mentioned in the manual may need to be exported from LISP
in order for things to work. This is because environment interface
functions are incompletely defined in the manual. It would be silly
to export a function from LISP and not be able to use it beacuse some
magic frob it needs isn't available.
2. Either the SYSTEM package or some implementation-specific package
should contain any implementation extensions to Common LISP. Might
as well make this the SYSTEM package.
I don't think extensions should come from the SYSTEM package. It
seems to me that there is a difference between a language extension
and a system dependent feature.
3. The USER package should use both the LISP and SYSTEM packages.
4. What should MAKE-PACKAGE use by default? Clearly the LISP package.
Probably not the SYSTEM package, although this would result in an
incompatible change for any implementation that currently puts all
public symbols in the LISP package. Such is life.
It is pretty wierd to say that USER should use the SYSTEM package yet
the default shouldn't include SYSTEM. USER is nothing if not the
default environment.
Date: Sunday, 9 March 1986 18:48-EST
From: Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
Re: Can, could, may, might, must, ...
The manual seems to take no stand on what should -not- be in the
LISP package. It says that the things in the book should be, but
it does not say, for example, whether it's appropriate to have the
LISP package use the SYSTEM package. ...
The main reason is that this makes porting between dialects a
pain. Suppose that some implementation has a symbol SYSTEM:FOO
which is a system constant. CLtL does not prohibit that symbol
being placed on the LISP package. But if I build and application
which builds a package on LISP, I have no assurance that doing
(DEFVAR FOO 3) will not be trying to redefine a system constant.
...
This seems confused. The packages which LISP uses has no effect on
packages which use LISP, since inherited symbols become internal
symbols.
Rob
∂10-Mar-86 0643 FAHLMAN@C.CS.CMU.EDU LISP package
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 10 Mar 86 06:43:20 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 10 Mar 86 09:17:00-EST
Date: Mon, 10 Mar 1986 09:16 EST
Message-ID: <FAHLMAN.12189589857.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: LISP package
I disagree rather strongly with the view that the Lisp package should be
exactly those symbols defined in the Common Lisp manual and no others.
My understanding of what these packages are for is based in part on the
Zetalisp package system, which was the starting point for the one in
Common Lisp.
The Lisp package has special status, in that it is the package that is
included by default in all others. It wants to contain those symbols
that should be accessible to typical applications in a given system --
the default set of accessible names.
The System package is for system-interface stuff and dangerous
implementation-dependent operations that do not want to be trivially
accessible to the average application.
I agree that it would occasionally be useful to have a package that is
guaranteed not to have anything in it that is not part of the Common
Lisp standard. We could create a new package, named "standard" or
something like that, to do this job. Or, I suppose, we could say that
the Lisp package does this job, and create a new package named "default"
or something that contains Common Lisp plus the local extensions. In
that case, "default" would replace "lisp" as the package used by default
when a new package is created. That's a more incompatible change for
most implementaitons.
I certainly do not like the idea of "system" being used to hold the
local stuff, and of folding it into the default. Then we would just
have to create another package to hold the dangerous "system" stuff like
(rewind-the-disk).
-- Scott
∂10-Mar-86 0715 FAHLMAN@C.CS.CMU.EDU True, False
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 10 Mar 86 07:14:54 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 10 Mar 86 09:48:39-EST
Date: Mon, 10 Mar 1986 09:48 EST
Message-ID: <FAHLMAN.12189595619.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Common-Lisp@SU-AI.ARPA
Subject: True, False
I've got no problem with the True and False functions, I guess. I'm not
100% sure that I like those names -- if I saw these in code, I would
tend to assume that they were predicates more or less equivalent to (not
(null ...)) and (null...). But I have nothing better to propose right
now.
Probably the best thing to do for now is to tack them onto the end of
the error proposal in a section labeled "Extensions to the Language" or
something like that.
I'm glad to hear that the error proposal is moving along.
-- Scott
∂10-Mar-86 0717 FAHLMAN@C.CS.CMU.EDU (LOAD ... :VERBOSE T)
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 10 Mar 86 07:17:24 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 10 Mar 86 09:51:03-EST
Date: Mon, 10 Mar 1986 09:50 EST
Message-ID: <FAHLMAN.12189596052.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: (LOAD ... :VERBOSE T)
In Spice Lisp, the :verbose option to load prints just an introductory
and completion message, while the :print option says something for each
item loaded. I think that this is what page 426 is trying to tell us,
though I admit that :verbose is described so loosely as to allow all
sorts of stuff to be printed. I would suggest a clarification that says
that :verbose is intended to print some useful information about the
file itself, but should not print anything about individual items in the
file.
It's too bad we chose those names, because they are confusing. :verbose
isn't very verbose and is not the most verbose of the available options.
I think we followed Maclisp in this. If the world were young, I would
suggest that :verbose print a comment for each item loaded, that the
default be to print just the "Loading FOO ...done." message, and that
there be a :silent keyword when you want to suppress all printout. But
this is probably not important enough to be worht an incompatible
change.
-- Scott
∂10-Mar-86 0729 DCP@ALLEGHENY.SCRC.Symbolics.COM Can, could, may, might, must, ...
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 10 Mar 86 07:27:52 PST
Received: from NEPONSET.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 3525; Mon 10-Mar-86 10:28:09-EST
Date: Mon, 10 Mar 86 10:28 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: Can, could, may, might, must, ...
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>,
"BACH::GREEK" <greek%bach.decnet@hudson.dec.com>,
Rob MacLachlan <RAM@C.CS.CMU.EDU>, Common-Lisp@SU-AI.ARPA
In-Reply-To: <860309184822.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
The message from "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>,
<RAM.12189526296.BABYL@C.CS.CMU.EDU>
Message-ID: <860310102822.0.DCP@NEPONSET.SCRC.Symbolics.COM>
I disagree with some people's opinions about what packages should
contain what.
LISP should contain only those things that are in the Silver Bible, or
ECO'd extensions. It should not include user interface things like QUIT
and SAVE-ALL-BUFFERs.
There should be a package that is defined by the vendor which contains
that vendor's EXTENSIONS. Symbolics has the Symbolics-Common-Lisp
package (aka SCL). This package contains language extensions and
external user interface items ONLY. It is NOT the system package and it
does NOT contain the implementation details (at least as exported
symbols) of LISP or the extensions. This package is the one to :USE
when writing Common Lisp programs specific to the vendor's system. To
write portable code, :USE the LISP package. The extended package either
uses and reexports all symbols in LISP, or imports and reexports to get
the same effect. (This allows a package to :use the extended package
without having to :use both. Maybe that isn't such a good idea, but
that's who Symbolics does it and it doesn't bother me.)
As stated above, the SYSTEM package is yet another beast. In the
Symbolics system (and probably the other derivitives from the MIT Lisp
Machine project), there are two rather different classes of things that
show up in here. One class is the external interface to the operating
system, such as SYSTEM:DISK-READ to issue a disk read. The other class
is the internal interface to the machine, such as instructions. This
has bothered me for a while, but I haven't had time to think about it
much.
The USER package can either use CL or use the extended CL package.
Symbolics makes it use the extended CL package since the extended
package contains a lot of user interface and is generally more useful
than the bare CL package. USER does NOT use SYSTEM. The USER package
is for dealing with the language and user interface, NOT the internals
of the implementation or the operating system.
Personally, I always specify a default for MAKE-PACKAGE :USE. That's
probably because our default is to :USE only LISP, which I think is the
right thing. :USE'ing any other packages would lead to name conflicts
KMP is trying to avoid.
The most important thing that I agree with KMP about is that the LISP
package contains only those symbols in CLtL.
∂10-Mar-86 0737 GRISS%HP-HULK@hplabs.ARPA Packages
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 10 Mar 86 07:36:51 PST
Received: from HP-HULK by hplabs.ARPA ; Mon, 10 Mar 86 07:36:46 pst
Date: Mon 10 Mar 86 07:36:28-PST
From: Martin <GRISS%HP-HULK@hplabs.ARPA>
Subject: Packages
To: common-LISP%su-ai@HPLABS
Cc: GRISS%HP-HULK@HPLABS
It seems to me that we do need a new package, called EXTENSIONS (or
some such) for new language features and reserve SYSTEM for those really
subtle/dangerous (rewind-the-disk -:) sort of things.
I am bothered by the notion that the LISP package should include all
kinds of implementation dependent symbols so that "other things can
work". To some degree, the LISP package lists the reserved words
(functions, globals, etc) of the Portable dialect.
I would like to see some examples of things in different
implementations that "MUST" be in LISP, yet are system dependent,
rather than being candidates for inclusion in the next CLtL?
Martin
-------
∂10-Mar-86 0742 shebs%utah-orion@utah-cs.arpa Re: LISP Package
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 10 Mar 86 07:41:29 PST
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA21692; Mon, 10 Mar 86 08:43:44 MST
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA23001; Mon, 10 Mar 86 08:43:40 MST
Date: Mon, 10 Mar 86 08:43:40 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8603101543.AA23001@utah-orion.ARPA>
To: common-lisp@su-ai.arpa
Subject: Re: LISP Package
In PCLS we've been very careful to export only standard things from LISP,
and use SYSTEM for anything that is PCLS dependent. The theory is that
it only takes one unqualified PCLS-specific symbol to ruin a programmer's
whole day - porting is hard enough when the necessary changes are obvious!
Even assuming something that every implementation "should have" (like
MULTIPLE-VALUE-SETF) is questionable.
I like Scott's suggestion of another package that exports exactly those
symbols defined in the standard. Existing user programs needn't change,
and if a user wanted to test for portability, s/he could tweak the list
of default use packages from (LISP ...) to (STANDARD), and see what
happens to the program...
stan
∂10-Mar-86 0819 greek%bach.decnet@hudson.dec.com What packages contain.
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 10 Mar 86 08:19:10 PST
Date: 0 0 00:00:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: What packages contain.
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
I agree with Dave Plummer. That sounds like the best organization.
LISP has only standard Common LISP stuff, and EXTENDED-LISP (say) has
all other public things. SYSTEM just has system hackery.
Now, what the USER package should use and what MAKE-PACKAGE should use
by default is still not completely clear. I think USER should get
everything (i.e., use both LISP and EXTENDED-LISP). Perhaps this is the
right default for MAKE-PACKAGE just for consistency's sake. A person
writing a layered product can just say to use only LISP.
- Paul
------
∂10-Mar-86 0845 DCP@ALLEGHENY.SCRC.Symbolics.COM True, False
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 10 Mar 86 08:43:16 PST
Received: from NEPONSET.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 3567; Mon 10-Mar-86 11:43:34-EST
Date: Mon, 10 Mar 86 11:43 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: True, False
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>, Common-Lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12189595619.BABYL@C.CS.CMU.EDU>
Message-ID: <860310114351.7.DCP@NEPONSET.SCRC.Symbolics.COM>
Date: Mon, 10 Mar 1986 09:48 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I've got no problem with the True and False functions, I guess. I'm not
100% sure that I like those names -- if I saw these in code, I would
tend to assume that they were predicates more or less equivalent to (not
(null ...)) and (null...). But I have nothing better to propose right
now.
KMP may have picked TRUE and FALSE for historical reasons. I wouldn't
mind more descriptive names, possibly which imply they take a set and
map the set to either boolean truth or boolean false. {-: Maybe we can
call these functions T and NIL :-}
Probably the best thing to do for now is to tack them onto the end of
the error proposal in a section labeled "Extensions to the Language" or
something like that.
I'm glad to hear that the error proposal is moving along.
-- Scott
∂10-Mar-86 0851 DCP@ALLEGHENY.SCRC.Symbolics.COM What packages contain.
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 10 Mar 86 08:50:51 PST
Received: from NEPONSET.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 3570; Mon 10-Mar-86 11:51:04-EST
Date: Mon, 10 Mar 86 11:51 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: What packages contain.
To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>,
common-lisp <common-lisp@SU-AI.ARPA>
In-Reply-To: The message from "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Message-ID: <860310115122.8.DCP@NEPONSET.SCRC.Symbolics.COM>
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Two thing: (1) Your mailer is specifying a completely out-to-lunch date
of
Date: 0 0 00:00:00 EST
and (2) there is no newline between your header and the first paragraph
of text, which implies the text is still part of the header.
I agree with Dave Plummer. That sounds like the best organization.
LISP has only standard Common LISP stuff, and EXTENDED-LISP (say) has
all other public things. SYSTEM just has system hackery.
I don't think it should be called EXTENDED-LISP. DEC's EXTENDED-LISP
package would not contain the same as Symbolic's EXTENDED-LISP package.
Now, what the USER package should use and what MAKE-PACKAGE should use
by default is still not completely clear.
I agree, as I stated in my last message.
I think USER should get
everything (i.e., use both LISP and EXTENDED-LISP).
Ditto.
Perhaps this is the right default for MAKE-PACKAGE just for consistency's sake.
I disagree. My current reason is that MAKE-PACKAGE is a CL tool to make
CL packages, and EXTENDED-LISP is not part of the default CL packages.
A person writing a layered product can just say to use only LISP.
Continuing... A person writing a layered product on CL need only use
MAKE-PACKAGE, which, after all, is pure CL. A person writing a layered
product based on the extended features of some other package must
explicitly use that package, which, after all, is not pure CL.
∂10-Mar-86 0906 DCP@ALLEGHENY.SCRC.Symbolics.COM LISP package
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 10 Mar 86 09:01:53 PST
Received: from NEPONSET.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 3578; Mon 10-Mar-86 12:02:13-EST
Date: Mon, 10 Mar 86 12:02 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: LISP package
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12189589857.BABYL@C.CS.CMU.EDU>
Message-ID: <860310120230.1.DCP@NEPONSET.SCRC.Symbolics.COM>
Date: Mon, 10 Mar 1986 09:16 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I disagree rather strongly with the view that the Lisp package should be
exactly those symbols defined in the Common Lisp manual and no others.
My understanding of what these packages are for is based in part on the
Zetalisp package system, which was the starting point for the one in
Common Lisp.
Please don't confuse the Zetalisp package system with the Zetalisp
GLOBAL package. The GLOBAL package is a crock of which at least half
is garbage and shouldn't be there. I'll let KMP tell you how it is hard
enough to write portable programs with extensions to functions in the CL
package, which will be after he tells you how to get screwed by having
non-CLtL symbols in the LISP package, which I thought he did in his
original message.
The Lisp package has special status, in that it is the package that is
included by default in all others. It wants to contain those symbols
that should be accessible to typical applications in a given system --
the default set of accessible names.
Wrong. The LISP package contains the Common Lisp language. Anything
else, ANYTHING, is not Common Lisp, but rather an extension. Extensions
belong in some other package or packages. Applications can use those
other packages in addition to LISP. This is a matter of documentation
by vendors for people writing such applications.
The System package is for system-interface stuff and dangerous
implementation-dependent operations that do not want to be trivially
accessible to the average application.
I agree that it would occasionally be useful to have a package that is
guaranteed not to have anything in it that is not part of the Common
Lisp standard. We could create a new package, named "standard" or
something like that, to do this job. Or, I suppose, we could say that
the Lisp package does this job, and create a new package named "default"
or something that contains Common Lisp plus the local extensions. In
that case, "default" would replace "lisp" as the package used by default
when a new package is created. That's a more incompatible change for
most implementaitons.
I certainly do not like the idea of "system" being used to hold the
local stuff, and of folding it into the default. Then we would just
have to create another package to hold the dangerous "system" stuff like
(rewind-the-disk).
-- Scott
∂10-Mar-86 0939 greek%bach.decnet@hudson.dec.com One More Apology
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 10 Mar 86 09:39:12 PST
Date: 0 0 00:00:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: One More Apology
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Let me apologize once more for our mailer software, which is written
by a company with an Australian-sounding name. Please don't ask us
to fix it, because we didn't write it and we don't have the time or
inclination to write a new mailer. So we wait until our vendor
fixes it.
Personally, I think any mail receiver that relies on a blank line to
separate the header from the body of the mail is brain-damaged.
But then again, I don't know anything about TCP/IP protocol or whatever.
And I don't want to.
Enough. Global apologies to all. I hope we get this fixed soon.
- Paul
------
∂10-Mar-86 0939 greek%bach.decnet@hudson.dec.com A package to contain Common LISP extensions.
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 10 Mar 86 09:39:38 PST
Date: 0 0 00:00:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: A package to contain Common LISP extensions.
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Of course DEC's EXTENDED-LISP package would contain different things
than Symbolic's. That's the purpose of the EXTENDED-LISP package.
Perhaps LISP-EXTENSIONS would be a better name. I just think that
everyone should agree on the name of the package to contain their
extensions. Then a user would at least have a place to start.
- Paul
------
∂10-Mar-86 0954 DCP@ALLEGHENY.SCRC.Symbolics.COM A package to contain Common LISP extensions.
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 10 Mar 86 09:54:07 PST
Received: from NEPONSET.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 3619; Mon 10-Mar-86 12:54:25-EST
Date: Mon, 10 Mar 86 12:54 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: A package to contain Common LISP extensions.
To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>,
common-lisp <common-lisp@SU-AI.ARPA>
In-Reply-To: The message from "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Message-ID: <860310125443.8.DCP@NEPONSET.SCRC.Symbolics.COM>
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Of course DEC's EXTENDED-LISP package would contain different things
than Symbolic's. That's the purpose of the EXTENDED-LISP package.
Perhaps LISP-EXTENSIONS would be a better name. I just think that
everyone should agree on the name of the package to contain their
extensions. Then a user would at least have a place to start.
To start what? I don't think there is such a thing as common
extensions, so it doesn't make much sense to me to agree to put our
uncommon extensions in a common package.
∂10-Mar-86 1032 greek%bach.decnet@hudson.dec.com The LISP-EXTENSIONS Package.
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 10 Mar 86 10:26:32 PST
Date: 0 0 00:00:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: The LISP-EXTENSIONS Package.
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
I'm not saying that there any common extensions. I'm just saying that
we should all agree to put our extensions in the same package, just like
we agree to put our system hacks in the SYSTEM package. Then the
CLtL could say "hey, any implementation-specific extensions are in
the LISP-EXTENSIONS package. Look there to find all kinds of goodies."
I'm only suggesting we agree on the package name, not on the contents.
- Paul
------
∂10-Mar-86 1047 FAHLMAN@C.CS.CMU.EDU Lisp package
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 10 Mar 86 10:40:07 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 10 Mar 86 13:13:40-EST
Date: Mon, 10 Mar 1986 13:13 EST
Message-ID: <FAHLMAN.12189632935.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Common-Lisp@SU-AI.ARPA
Subject: Lisp package
In response to David Plummer:
Wrong. The LISP package contains the Common Lisp language. Anything
else, ANYTHING, is not Common Lisp, but rather an extension. Extensions
belong in some other package or packages. Applications can use those
other packages in addition to LISP. This is a matter of documentation
by vendors for people writing such applications.
It does not say anywhere that the Lisp package contains ONLY the Common
Lisp language. That's certainly one way to handle this, but it is not
obvious that this is the best way, regardless of how forcefully you
choose to state this opinion.
I agree that it would be useful to have separate packages for "pure"
Common Lisp and for the richer default environment provided by a given
implementation. It seems clear to me that the latter is what should be
used by Make-Package unless the user specifies otherwise, since this is
what the implementors of the system believe that the user will typically
want to have around. The only remaining issue is which of these
concepts gets to use the name Lisp, and which has to find a new name.
-- Scott
∂10-Mar-86 1111 JAR@MC.LCS.MIT.EDU A package to contain Common LISP extensions.
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 10 Mar 86 10:46:16 PST
Date: Mon, 10 Mar 86 13:46:58 EST
From: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
Subject: A package to contain Common LISP extensions.
To: greek%bach.decnet@HUDSON.DEC.COM
cc: common-lisp@SU-AI.ARPA
In-reply-to: Msg of 0 0 00:00:00 EST from BACH::GREEK <greek%bach.decnet at hudson.dec.com>
Message-ID: <[MC.LCS.MIT.EDU].845405.860310.JAR>
Date: 0 0 00:00:00 EST
From: BACH::GREEK <greek%bach.decnet at hudson.dec.com>
Of course DEC's EXTENDED-LISP package would contain different things
than Symbolic's. That's the purpose of the EXTENDED-LISP package.
Perhaps LISP-EXTENSIONS would be a better name. I just think that
everyone should agree on the name of the package to contain their
extensions. Then a user would at least have a place to start.
I don't see why there should be agreement, as each implementation's
extensions will be different. In fact, I would think each
implementation would want its own package name for its extensions, in
order to improve readability and reduce the potential for accidental
name conflicts (which could otherwise be painful to track down). Also,
one could imagine creating compatibility-mode implementations of one set
of extensions to co-reside with another set, making it even more
desirable to have disjoint packages.
The only reason I can think of for having a standard name for a package
of extensions is to give users a way to create "things like the USER
package" which have local extensions. This seems of marginal utility in
portable code, but perhaps a standard nickname would be in order if
people think it's important.
Of course all this begs the question of how to avoid package name
conflicts, but that's not a new problem created by this situation. I
think a package name registry would be a good idea, although not a
complete solution; the only problem with it would be getting people to
make use of it.
---
Having attempted to write portable CL code, and having repeatedly
tromped on implementation-dependent things in the LISP package which I
would have preferred to not be there (not just symbols like QUIT and
HELP, but definitions as well - e.g. Symbolics Common Lisp defines an
IGNORE function), I want to put myself on record as opposed to putting
non-CL things in the LISP package or in value (function, etc.) cells of
symbols in the LISP package.
As long as I'm flaming on this subject, I'll mention my idle desire that
the HOME package of symbols in the LISP package be defined to be the
LISP package. This would permit true read/print symmetry (e.g. across
implementations or different versions of the same implementation) for
shadowed LISP package symbols.
Jonathan
∂10-Mar-86 1135 REM@IMSSS Package for exactly CLtL and nothing else
Received: from IMSSS by SU-AI with PUP; 10-Mar-86 11:28 PST
Date: 10 Mar 1986 1125-PST
From: Rem@IMSSS
Subject: Package for exactly CLtL and nothing else
To: COMMON-LISP@SU-AI
I agree with all the people who want some package with an agreed-upon name
to be exactly CLtL and nothing else, because it makes benchmarking easier,
you just map down the package to verify every function is there and nothing
else there, and having done that gross count you then proceed with detailed
testing of each and every function in that package.
As to its name, that's unclear. SInce we're liable to have different versions
of CLtL every so years as we improve the specification, either LISP or CLTL
is probably a bad name, although CLTL86 would be a good name for this year's
standard. If CLTL86 happened to be identical to LISP on some systems and
not on other systems, I wouldn't mind. The documentation for that system
should say what packages are available beyond CLTL86 and what is in them.
If the exactly-CLTL package were year-numbered, it would be possible for
one implementation to provide several different years of standard at the
same time, and portable code could use exactly the package it was written for
without incompatible changes from year to year goofing it up, and there'd
be a graceful period of overlap instead of a flag day when a given vendor's
implementation switches years (or two incompatible LISP environments where
the poor user can't mix usage of the two).
Therefore I propose that as soon as CLtL is absolutely firm, we stamp it
with a yearmark and establish the package name to contain that version;
debate on this proposal invited...
-------
∂10-Mar-86 1313 Dan@THINK-AQUINAS.ARPA Package for exactly CLtL and nothing else
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 10 Mar 86 11:54:55 PST
Received: from christopher by GODOT.THINK.COM via CHAOS; Mon, 10 Mar 86 14:55:28 est
Date: Mon, 10 Mar 86 14:57 EST
From: Dan Aronson <Dan@THINK-AQUINAS.ARPA>
Subject: Package for exactly CLtL and nothing else
To: Rem@IMSSS, common-lisp@SU-AI.ARPA
In-Reply-To: <8603101937.AA02525@GODOT.THINK.COM>
Message-Id: <860310145729.3.DAN@THINK-CHRISTOPHER.ARPA>
From: Rem@IMSSS
Subject: Package for exactly CLtL and nothing else
... , it would be possible for
one implementation to provide several different years of standard at the
same time, and portable code could use exactly the package it was written for
without incompatible changes from year to year goofing it up, and there'd
be a graceful period of overlap instead of a flag day when a given vendor's
implementation switches years (or two incompatible LISP environments where
the poor user can't mix usage of the two).
...
Wait a minute. Are you suggesting that lisps should be required to
have a whole bunch of almost identical implementations, each loaded
up in a different package. Since most of the language probably
will remain fairly constant this is a fairly large waste of space.
(or a large effort for the implementor to figure out how to share
common function, etc.)
Since we are hoping for a standard I don't think that the language
will change all that much so that the code really needs to use
a completely different lisp system. I vote for having one
standard package.
--Dan
∂10-Mar-86 1346 gls@THINK-AQUINAS.ARPA TRUE, FALSE
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 10 Mar 86 12:46:29 PST
Received: from yon by GODOT.THINK.COM via CHAOS; Mon, 10 Mar 86 15:46:57 est
Date: Mon, 10 Mar 86 15:48 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: TRUE, FALSE
To: KMP@SCRC-STONY-BROOK.ARPA, Common-Lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <860309184010.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-Id: <860310154859.2.GLS@THINK-YON.ARPA>
Date: Sun, 9 Mar 86 18:40 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
For the next edition, could we introduce functions TRUE and FALSE ...
Why not just a function CONSTFN that takes a value and returns a function
that will return that value?
(DEFUN CONSTFN (X) #'(LAMBDA (&REST Z) (DECLARE (IGNORE Z)) X))
or, for more generality:
(DEFUN CONSTFN (&REST X) #'(LAMBDA (&REST Z) (DECLARE (IGNORE Z)) (VALUES-LIST X)))
Then instead of #'TRUE you just say (CONSTFN T). All very Schemish.
(And I know at least thirty people out there will scream with horror,
"But that CONSES!" and they will be right.)
--Guy
∂10-Mar-86 1431 FAHLMAN@C.CS.CMU.EDU TRUE, FALSE
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 10 Mar 86 14:16:05 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 10 Mar 86 17:15:38-EST
Date: Mon, 10 Mar 1986 17:15 EST
Message-ID: <FAHLMAN.12189676981.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Guy Steele <gls@AQUINAS.THINK.COM>
Cc: Common-Lisp@SU-AI.ARPA
Subject: TRUE, FALSE
In-reply-to: Msg of 10 Mar 1986 15:48-EST from Guy Steele <gls at THINK-AQUINAS.ARPA>
Why not just a function CONSTFN that takes a value and returns a function
that will return that value?
So far only two such functions have been asked for, one of which
produces a null value and the other of which produces something
non-null: T, for lack of any better thing. Do we really need a
general function to build such things? I don't think so.
Down with generality, and down with the generals!
-- Scott
∂10-Mar-86 1450 DCP@SCRC-STONY-BROOK.ARPA The LISP-EXTENSIONS Package.
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 10 Mar 86 14:47:43 PST
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 434635; Mon 10-Mar-86 17:33:23-EST
Date: Mon, 10 Mar 86 17:35 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: The LISP-EXTENSIONS Package.
To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>,
common-lisp <common-lisp@SU-AI.ARPA>
In-Reply-To: The message from "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Message-ID: <860310173508.1.DCP@NEPONSET.SCRC.Symbolics.COM>
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
I'm not saying that there any common extensions. I'm just saying that
we should all agree to put our extensions in the same package, just like
we agree to put our system hacks in the SYSTEM package. Then the
CLtL could say "hey, any implementation-specific extensions are in
the LISP-EXTENSIONS package. Look there to find all kinds of goodies."
The manual says very little about what goes in the SYSTEM package. The
Symbolics implementation has several other packages where 'system hacks'
live, such as the network package, the TV package, the debugger package,
etc. I'm flaming. Sorry. My first opinion was probably my best. It
is in the archive, and I'll let that opinion stand.
I'm only suggesting we agree on the package name, not on the contents.
∂10-Mar-86 1604 DCP@SCRC-QUABBIN.ARPA TRUE, FALSE
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 10 Mar 86 15:05:57 PST
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 252084; Mon 10-Mar-86 18:03:40-EST
Date: Mon, 10 Mar 86 18:06 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: TRUE, FALSE
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>,
Guy Steele <gls@AQUINAS.THINK.COM>
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12189676981.BABYL@C.CS.CMU.EDU>
Message-ID: <860310180600.0.DCP@NEPONSET.SCRC.Symbolics.COM>
Date: Mon, 10 Mar 1986 17:15 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Why not just a function CONSTFN that takes a value and returns a function
that will return that value?
So far only two such functions have been asked for, one of which
produces a null value and the other of which produces something
non-null: T, for lack of any better thing. Do we really need a
general function to build such things? I don't think so.
Down with generality, and down with the generals!
Another way to look at this is that common cliches should have a
defined, common, abstraction.
∂10-Mar-86 1604 GJC@MC.LCS.MIT.EDU "But that CONSES?"
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 10 Mar 86 15:04:57 PST
Date: Mon, 10 Mar 86 18:05:46 EST
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Subject: "But that CONSES?"
To: gls@AQUINAS.THINK.COM
cc: Common-Lisp@SU-AI.ARPA, KMP@SCRC-STONY-BROOK.ARPA
In-reply-to: Msg of Mon 10 Mar 86 15:48 EST from Guy Steele <gls at THINK-AQUINAS.ARPA>
Message-ID: <[MC.LCS.MIT.EDU].845835.860310.GJC>
They could be very wrong. If CONSTFN is declared to be integrable
then (CONSTFN T) could very well return the same thing, #'TRUE, every time.
No need to cons.
∂10-Mar-86 1604 Gregor.pa@Xerox.COM Re: A package to contain Common LISP extensions.
Received: from XEROX.COM by SU-AI.ARPA with TCP; 10 Mar 86 15:11:42 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 10 MAR 86 14:21:31 PST
Date: 10 Mar 86 13:28 PST
From: Gregor.pa@Xerox.COM
Subject: Re: A package to contain Common LISP extensions.
In-reply-to: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>'s message of Mon,
10 Mar 86 12:54 EST
To: DCP@SCRC-QUABBIN.ARPA
cc: greek%bach.decnet@hudson.dec.com, common-lisp@SU-AI.ARPA
Message-ID: <860310-142131-1093@Xerox>
From my experience porting Portable CommonLoops I have the following
opinions on this subject:
* I feel VERY STRONGLY that the lisp package should have only those
symbols defined in CLTL.
Here are some examples of problems I have had with Common Lisps in which
this wasn't true, (I do not mean to point fingers, I am just trying to
use concrete examples):
In an early version of Lucid Lisp memq was in the lisp package. It was
also a special function so that when PCL redefined it as a macro the
lisp got a bad headache.
On the Explorer string-append is defined in the lisp package. When you
load pcl is says "Warning... redefining string append, OK?" You say
yes, but then the editor breaks because they have extended string-append
to do some special stuff for the editor.
I KCL there are so many extra symbols in the lisp package that its easy
to use one of them without knowing it.
* make-package should inherit from lisp.
* I see no reason to specify the name of the package where people should
put their extensions. Extensions go in lots of different packages based
upon their nature, it would be cumbersome to have to decide if a
particular function deserves to be a "common Lisp extension" and should
be movce to the extensions package. Hmm should
zwei:with-output-to-buffer be in the extensions package.
In order for a programmer to make use of the extensions that a given
implementation offers they are going to have to spend enough time
reading about those extensions and interfacing them to their program
that the time it will take them to type a few IMPORTs or use-packages
will be insignificant. But someone who tries real hard to make a
program that really is portable should have as much of a chance at
wining as possible and extra symbols in the Lisp package get in the way.
∂10-Mar-86 1604 DCP@SCRC-QUABBIN.ARPA TRUE, FALSE
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 10 Mar 86 15:09:05 PST
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 252085; Mon 10-Mar-86 18:03:51-EST
Date: Mon, 10 Mar 86 18:06 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: TRUE, FALSE
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>,
Guy Steele <gls@AQUINAS.THINK.COM>
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12189676981.BABYL@C.CS.CMU.EDU>
Message-ID: <860310180613.1.DCP@NEPONSET.SCRC.Symbolics.COM>
Date: Mon, 10 Mar 1986 17:15 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Why not just a function CONSTFN that takes a value and returns a function
that will return that value?
So far only two such functions have been asked for, one of which
produces a null value and the other of which produces something
non-null: T, for lack of any better thing. Do we really need a
general function to build such things? I don't think so.
Down with generality, and down with the generals!
Another way to look at this is that standard cliches should have a
defined, common, abstraction.
∂10-Mar-86 1731 KMP@SCRC-STONY-BROOK.ARPA The LISP-EXTENSIONS Package.
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 10 Mar 86 17:30:54 PST
Received: from HUMMINGBIRD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 434784; Mon 10-Mar-86 20:24:36-EST
Date: Mon, 10 Mar 86 20:25 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: The LISP-EXTENSIONS Package.
To: greek%bach.decnet@hudson.dec.com, common-lisp@SU-AI.ARPA
In-Reply-To: The message from "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Message-ID: <860310202519.1.KMP@HUMMINGBIRD.SCRC.Symbolics.COM>
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: The LISP-EXTENSIONS Package.
I'm not saying that there any common extensions. I'm just saying that
we should all agree to put our extensions in the same package, just like
we agree to put our system hacks in the SYSTEM package. Then the
CLtL could say "hey, any implementation-specific extensions are in
the LISP-EXTENSIONS package. Look there to find all kinds of goodies."
Are you arguing that people should do (APROPOS "" "SYSTEM") and try calling
things that look fun? Each implementation will have to document its goodies,
and in that documentation they can tell you any package you want. There is
no reason for CL to standardize on that package name and a lot of reason for
CL not to (read on)...
I'm only suggesting we agree on the package name, not on the contents.
The problem is that if one writes:
(DEFUN FOO (X) (LISP-EXTENSIONS:FROB X))
they may find out that FROB is defined differently in two different systems.
When a program is written for one implementation and later ported to another,
you may get no compiler warnings since the compiler may not realize that
the LISP-EXTENSIONS:FROB you're calling is not the one you meant.
Consider the following awful situation, where two implementations have
FROB1 and FROB2, but where the two have oppposite meanings...
(DEFUN FOO (X)
(COND (X #+SOMETHING (LISP-EXTENSIONS:FROB1 X)
#-SOMETHING (LISP-EXTENSIONS:FROB2 X))
(T
#+SOMETHING (LISP-EXTENSIONS:FROB2 X)
#-SOMETHING (LISP-EXTENSIONS:FROB1 X))))
This program is very hard to look at. The following program is not much
prettier, but is a least something which one can begin to fathom at a glance...
(DEFUN FOO (X)
(COND (X #+SOMETHING (MY:FROB1 X)
#-SOMETHING (YOUR:FROB2 X))
(T
#+SOMETHING (MY:FROB2 X)
#-SOMETHING (YOUR:FROB1 X))))
This actually comes up in things like file manipulation tools, math (especially
trig) functions, and other such things where the concepts have well defined names,
but where the exact datatypes and ranges of inputs and outputs can vary widely.
I agree with those at Symbolics who've said there are good reasons for our
having picked SCL: for Symbolics extensions and not dumped all that in
a standardly named package. At least if SCL:symbols are read into another Lisp,
you'll know right away that you have a portability problem -- an effect which
I have found to be an important -aid- to portability.
∂10-Mar-86 2020 NETS.NRTC@USC-ECL.ARPA Re Scope and declarations
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 10 Mar 86 20:19:59 PST
Date: Mon, 10 Mar 86 19:01:24 PST
From: Jeff Barnett <jbarnett%NRTC@USC-ECL.ARPA>
To: common-lisp@SU-AI.ARPA
Subject: Re Scope and declarations
Via: Nrtc; 10 Mar 86 20:04:19
Sorry I wasn't specific enough in my last query. Therefore, I'll start from
scratch. The point that bothers me is the one made on page 155 of CLtL.
As I understand things,
(setq x 5)
(defun foo (x)
(declare (unspecial x))
(let((x (1+ x)))
(declare (special x))
x)
(print (foo 0))
outputs 6, not 1. The declare in the let form prevades the preset expression
so that the expression (1+ x) assumes the current global binding of x outside
outside the let. I can understand that this will often be the right thing and
require less writing. I also understand that if I want to grab the lexical x
that I could change the let to start
(let((x (let()(declare (unspecial x)) (1+ x))))
which I suppose works. (Does it?) However, if the let is produced by a
macro, there is no way to achieve this effect unless the macro can enumerate
the scope of the expression that it uses for the preset. Since the preset
may be passed into the macro, I don't think it can recover in any graceful
way unless you think that
(let((g exp))
(let((x g))
(declare (special x)) etc))
where g is a gensym, is graceful.
Another problem with declares prevading presets is that the following are
not equivelent:
(let((v1 e1) (v2 e2)) (declare (something-about v1 v2)) body...)
((lambda(v1 v2) (declare (something-about v1 v2)) body...) e1 e2)
Further, I think the proposed standard is incompatible with virtually all
other LISP implementations. I don't think that this is a good idea for CL.
Any comments and clarifications as to all of this would be appreciated.
Jeff
∂10-Mar-86 2020 NETS.NRTC@USC-ECL.ARPA compiler-let and macrolet in macros
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 10 Mar 86 20:20:15 PST
Date: Mon, 10 Mar 86 19:14:01 PST
From: Jeff Barnett <jbarnett%NRTC@USC-ECL.ARPA>
To: common-lisp@SU-AI.ARPA
Subject: compiler-let and macrolet in macros
Via: Nrtc; 10 Mar 86 20:04:42
Consider the following hack.
(defmacro with-car (&body body)
`(compiler-let((operator 'car))
,. body))
(defmacro with-cdr (&body body)
`(compiler-let((operator 'cdr))
,. body)
(defmacro right-side (exp) `(,operator ,exp))
What I want to know is will the following work
(setf (with-car (right-side foo)) (with-cdr (right-side goo)))
Probably not. Of course this can be transformed into
(with-car (setf (right-side foo) (with-cdr (right-side goo))))
However, I think the latter is more obscure. By the way, I don't believe
that an implementation of this sort using macrolet will work either.
The point of all of this is that macroexpand does not expand either
compiler-let or macrolet. Thus, setf can't see its real arguments. There
is a solution to this kind of problem but it would require much more
sophisticated macro expansion than is done today or has been proposed.
Before, I endeavor to write up a proposal for better macro expansion
facilities, I want to know if anybody is interested in either the problem or
its solution.
Jeff
∂11-Mar-86 0707 gls@THINK-AQUINAS.ARPA TRUE, FALSE
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 11 Mar 86 07:07:21 PST
Received: from guido by GODOT.THINK.COM via CHAOS; Tue, 11 Mar 86 10:07:22 est
Date: Tue, 11 Mar 86 10:09 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: TRUE, FALSE
To: Fahlman@C.CS.CMU.EDU, gls@THINK-AQUINAS.ARPA
Cc: Common-Lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA
In-Reply-To: <FAHLMAN.12189676981.BABYL@C.CS.CMU.EDU>
Message-Id: <860311100923.1.GLS@GUIDO.THINK.COM>
Date: Mon, 10 Mar 1986 17:15 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Why not just a function CONSTFN that takes a value and returns a function
that will return that value?
So far only two such functions have been asked for, one of which
produces a null value and the other of which produces something
non-null: T, for lack of any better thing. Do we really need a
general function to build such things? I don't think so.
Down with generality, and down with the generals!
-- Scott
The issue isn't generality, but minimizing the number of new functions.
"Why take two when one will do?"
--Guy
∂11-Mar-86 0719 greek%bach.decnet@hudson.dec.com Where do extensions go?
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 11 Mar 86 07:19:05 PST
Date: 11 Mar 86 10:07:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: Where do extensions go?
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
I agree that different implementations might have lots of packages with
different extensions in them (e.g., debugger, editor). It just seems
a pain if you don't import all of these into one extensions package and
then make them public from there. Otherwise the user has to use all
sorts of packages or put package prefixes everywhere.
In particular, Common LISP says that there will probably be a debugger
(for example), but doesn't talk about the interface. So the user says
"I want to use the debugger, where the hell is it? Which packages do I
have to use so that any symbols that are part of the debugger will show
up? Do I need to use more than one package?" It seems we could avoid
some of this annoyance if we just said that all such public symbols are
in some standard package.
Of course there might be confusion between two implementations. But
that isn't any worse or better if we agree on the name of the extensions
package. Also, by agreeing on one name, we only reserve that one name,
and we don't potentially have a bunch of names that layered product
developers have to avoid. This is particularly important if we refuse
to register package names, which we probably will.
- Paul
------
∂11-Mar-86 0731 FAHLMAN@C.CS.CMU.EDU TRUE, FALSE
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 11 Mar 86 07:31:19 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 11 Mar 86 10:19:58-EST
Date: Tue, 11 Mar 1986 10:19 EST
Message-ID: <FAHLMAN.12189863451.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Guy Steele <gls@AQUINAS.THINK.COM>
Cc: Common-Lisp@SU-AI.ARPA
Subject: TRUE, FALSE
In-reply-to: Msg of 11 Mar 1986 10:09-EST from Guy Steele <gls at THINK-AQUINAS.ARPA>
The issue isn't generality, but minimizing the number of new functions.
"Why take two when one will do?"
--Guy
In my view, the complexity of a language is not measured by counting the
functions. One hairy function-building meta-function adds a lot more
conceptual hair than two nearly identical simple functions that just do
easily explained things: gobble down any number of arguments, ignore
them, and return T or NIL. I'm not sure where the break-even point
would be in this case, but it's a lot higher than two.
-- Scott
∂11-Mar-86 0757 gls@THINK-AQUINAS.ARPA TRUE, FALSE
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 11 Mar 86 07:57:31 PST
Received: from guido by GODOT.THINK.COM via CHAOS; Tue, 11 Mar 86 10:57:54 est
Date: Tue, 11 Mar 86 10:59 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: TRUE, FALSE
To: Fahlman@C.CS.CMU.EDU, gls@THINK-AQUINAS.ARPA
Cc: Common-Lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA
In-Reply-To: <FAHLMAN.12189863451.BABYL@C.CS.CMU.EDU>
Message-Id: <860311105957.5.GLS@GUIDO.THINK.COM>
Date: Tue, 11 Mar 1986 10:19 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
The issue isn't generality, but minimizing the number of new functions.
"Why take two when one will do?"
--Guy
In my view, the complexity of a language is not measured by counting the
functions. One hairy function-building meta-function adds a lot more
conceptual hair than two nearly identical simple functions that just do
easily explained things: gobble down any number of arguments, ignore
them, and return T or NIL. I'm not sure where the break-even point
would be in this case, but it's a lot higher than two.
-- Scott
That's fair, of course, but I'll rpess my luck just one more time: we
would be better off if we didn't automatically think of functions that
return functions as "hairy". (I don't mean to accuse you of reacting
automatically in this case, but I don't think my CONSTFN one-liner was
any hairier than + or GCD.) We are all used to MAPC and MAPCAR; most of
us are used to REMOVE-IF-NOT by now; and I have found REDUCE to be
tremendously useful in unexpected ways, as I have already noted. There
is great expressive power to be gained in a carefully selected set of
function-producing functions.
∂11-Mar-86 0802 DLW@ALLEGHENY.SCRC.Symbolics.COM Meta-issue
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 11 Mar 86 08:02:09 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 3853; Tue 11-Mar-86 11:01:44-EST
Date: Tue, 11 Mar 86 11:01 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Meta-issue
To: common-lisp@SU-AI.ARPA
Message-ID: <860311110129.5.DLW@CHICOPEE.SCRC.Symbolics.COM>
I'd like to make a point at the meta-level, i.e., about how we go about
evaluating Common Lisp clarification/redesign decisions. A major goal
of Common Lisp was to allow portability of serious, large Lisp programs.
After all these years, we are finally seeing a few efforts to do develop
such portable software. In all my time as a computer engineer, I have
found that experience from practical implementation efforts is
irreplacable, and "packs more punch" than speculative opinion in
general. We should pay close attention to the experiences of KMP,
Gregor, and others if we seriously want to make Common Lisp useful for
serious portable software.
∂11-Mar-86 0840 DLW@ALLEGHENY.SCRC.Symbolics.COM Where do extensions go?
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 11 Mar 86 08:39:18 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 3877; Tue 11-Mar-86 11:39:02-EST
Date: Tue, 11 Mar 86 11:38 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Where do extensions go?
To: greek%bach.decnet@hudson.dec.com, common-lisp@SU-AI.ARPA
In-Reply-To: The message of 11 Mar 86 10:07-EST from "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Message-ID: <860311113844.1.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: 11 Mar 86 10:07:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
I agree that different implementations might have lots of packages with
different extensions in them (e.g., debugger, editor). It just seems
a pain if you don't import all of these into one extensions package and
then make them public from there. Otherwise the user has to use all
sorts of packages or put package prefixes everywhere.
What if there is more than one "extension", and two extensions use the
same name for something? Think about why there are packages in the first
place.
In particular, Common LISP says that there will probably be a debugger
(for example), but doesn't talk about the interface. So the user says
"I want to use the debugger, where the hell is it? Which packages do I
have to use so that any symbols that are part of the debugger will show
up? Do I need to use more than one package?" It seems we could avoid
some of this annoyance if we just said that all such public symbols are
in some standard package.
OK, so then you'd know what package the interface was in. But you still
would not know what any of the functions did. So you need a
specification (documentation). Since you need that anyway, it can tell
you what package to use.
Of course there might be confusion between two implementations. But
that isn't any worse or better if we agree on the name of the extensions
package. Also, by agreeing on one name, we only reserve that one name,
and we don't potentially have a bunch of names that layered product
developers have to avoid. This is particularly important if we refuse
to register package names, which we probably will.
I think the problem here is that you are assuming that each Common Lisp
system comes with one single set of "extensions", produced by the same
people that provide the base language, and that these sets of
"extensions" are inherently different in some way from other packages of
useful functions produced by other parties.
∂11-Mar-86 0918 RPG TRUE, FALSE
To: common-lisp@SU-AI.ARPA
Rememeber, also, that Common Lisp designers have traditionally adopted the
S-1 motto:
Why use lead when gold will do?
-rpg-
∂11-Mar-86 1000 nelson%bach.decnet@hudson.dec.com package names
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 11 Mar 86 09:39:10 PST
Date: 11 Mar 86 12:23:00 EST
From: "BACH::NELSON" <nelson%bach.decnet@hudson.dec.com>
Subject: package names
To: "common-lisp" <common-lisp@su-ai.arpa>
Reply-To: "BACH::NELSON" <nelson%bach.decnet@hudson.dec.com>
If it is clear that package names should be different between
implementations, how do we assure that they are different? Have
each implementation insert a vendor or system prefix (e.g. DEC-EDITOR::,
SYMBOLICS-EDITOR::, PSL-VAX-UNIX-EDITOR::)? Ick. Or require, as Paul
Anagnastopoulos has suggested, that package names be registered? It
seems like this can easily become an intractable problem. There will be lots
of editors and debuggers and other programs. I accept the arguments for
encouraging that implementation-specific, accessible, functions be in
packages uniquely named for each implementation, but the only naming
conventions which come to mind are the two mentioned above. Does anyone
have any other suggestions?
Regarding the functions which Guy suggested for generating functions -
they don't seem any more weird than the functions that they generate.
Beryl Nelson
------
∂11-Mar-86 1003 greek%bach.decnet@hudson.dec.com Having lots of packages with extensions.
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 11 Mar 86 09:39:34 PST
Date: 11 Mar 86 12:34:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: Having lots of packages with extensions.
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
In response to Mr. Weinreb:
Yes, I was clearly being too general. I agree that there may be lots
of packages provided by a company with their Common LISP. Not all of
the public symbols in these packages want to be imported into some
"extensions" package. We certainly have such packages in VAX LISP.
I'm thinking more of general extensions that are used at top level for
various random things. Those symbols that a person would expect to just
have at top level in the USER package without having to use some special
package or package prefix. Symbols which fall into the category of ED
or DEBUG or the like. This is the reason Common LISP defined ED to
invoke the editor rather than just saying that "there might be an
editor."
Perhaps this is simply too nebulous to define. I'd be happy, I guess,
if we just said that the LISP package contains exactly Common LISP and
lots of other packages might exist with various extra goodies. I sure
feel uncomfortable, however, if we don't at least say that all those
extra packages follow some naming convention, like SYSTEM-xxx.
Otherwise a layered product simply does not know what names it can use
for its packages.
Furthermore, if we say that there can be arbitrary packages with
extensions, then what the hell are we bothering to define the SYSTEM
package for?
- Paul
------
∂11-Mar-86 1058 DLW@ALLEGHENY.SCRC.Symbolics.COM TRUE, FALSE
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 11 Mar 86 10:57:53 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 3932; Tue 11-Mar-86 13:57:41-EST
Date: Tue, 11 Mar 86 13:57 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: TRUE, FALSE
To: Fahlman@C.CS.CMU.EDU
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12189863451.BABYL@C.CS.CMU.EDU>
Message-ID: <860311135722.7.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Tue, 11 Mar 1986 10:19 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I'm not sure where the break-even point
would be in this case, but it's a lot higher than two.
I'd say the key question is whether we anticipate that this function
generator might be used for other things besides these two things, in
the future. If we think there would be many other things, that would
support the proposal for the function generator.
In turn, this depends partially on how much we think people will be
using functional objects, closures, and function generators. That's
what GLS's last message was about. Appropriate design of Common Lisp
can only be done in the presence of a presumed programming style, to
allow us to try to gague how useful certain proposed features will be in
the future. It's a hard problem because we don't all use the same
programming style, and because programming styles change with time.
In developing Common Lisp, I don't think we were completely consistent
in our treatment of these issues. (Controversial statement of the
year...) Some things in Common Lisp, notably the sequence functions,
were a little bit outside of what most of us considered the usual
programming style, for example. This is presumably because we felt that
the style of the sequence functions was in the direction that we felt
modern Lisp was going. This is also one of the reasons that lexical
scoping was adopted, although there were certainly others.
I think that GLS's proposed function generator is also in the direction
that model Lisp style is moving towards. However, we don't all have the
same opinions about style. Also, it's not clear how far out Common
Lisp, as a broad standard, should reach. While we don't want to be
mired in the past, we also have a responsibility to be generally
conservative in some ways, because of the large number of
implementations and users. So I think it's a complex judgement call.
∂11-Mar-86 1236 DLW@ALLEGHENY.SCRC.Symbolics.COM :if-does-not-exist
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 11 Mar 86 12:34:28 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 3990; Tue 11-Mar-86 15:34:03-EST
Date: Tue, 11 Mar 86 15:33 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: :if-does-not-exist
To: common-lisp@SU-AI.ARPA
Message-ID: <860311153347.1.DLW@CHICOPEE.SCRC.Symbolics.COM>
The description of the default value of the :if-does-not-exist argument
to open, on page 422, confused our implementor. Strictly read, the
manual is ambiguous about the default value, in the case where
:direction is :probe and :if-exists is :overwrite or :append. The
intention of the manual is probably that you realize that :if-exists is
not defined for :probe, but this is not completely clear from the text.
This should be clarified in the next edition.
∂11-Mar-86 1357 Moon@ALLEGHENY.SCRC.Symbolics.COM compiler-let and macrolet in macros
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 11 Mar 86 13:57:31 PST
Received: from LONG-TAILED-JAEGER.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 4066; Tue 11-Mar-86 16:57:12-EST
Date: Tue, 11 Mar 86 16:59 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: compiler-let and macrolet in macros
To: Jeff Barnett <jbarnett%NRTC@USC-ECL.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 10 Mar 86 22:14-EST from Jeff Barnett <jbarnett%NRTC@USC-ECL.ARPA>
Message-ID: <860311165932.5.MOON@LONG-TAILED-JAEGER.SCRC.Symbolics.COM>
Date: Mon, 10 Mar 86 19:14:01 PST
From: Jeff Barnett <jbarnett%NRTC@USC-ECL.ARPA>
Consider the following hack.
(defmacro with-car (&body body)
`(compiler-let((operator 'car))
,. body))
(defmacro with-cdr (&body body)
`(compiler-let((operator 'cdr))
,. body))
(defmacro right-side (exp) `(,operator ,exp))
What I want to know is will the following work
(setf (with-car (right-side foo)) (with-cdr (right-side goo)))
Probably not. Of course this can be transformed into
(with-car (setf (right-side foo) (with-cdr (right-side goo))))
However, I think the latter is more obscure.
(define-setf-method compiler-let (bindings single-body-form)
(progv (mapcar #'first bindings)
(mapcar #'eval (mapcar #'second bindings))
(get-setf-method-multiple-value single-body-form)))
makes it work for me. Perhaps if I thought about it more I would come up
with a subtle reason why this works for your example but cannot work in the
most general case. Perhaps it should wrap the COMPILER-LET back around
the fourth and fifth values before returning them.
The reason define-setf-method is included in the language is precisely to
provide a portable way to do hairy things like this.
By the way, I don't believe
that an implementation of this sort using macrolet will work either.
I think it would if Common Lisp included a portable way to manipulate the function
environment in the same way that progv provides a portable way to manipulate the
special-variable environment.
∂11-Mar-86 1449 KMP@ALLEGHENY.SCRC.Symbolics.COM Some notes about declarations
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 11 Mar 86 14:49:13 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 4116; Tue 11-Mar-86 17:48:49-EST
Date: Tue, 11 Mar 86 17:48 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Some notes about declarations
To: Common-Lisp@SU-AI.ARPA
Message-ID: <860311174837.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Do we provide a way to type-declare functions (ie, FTYPE) that have
&optional or &rest specifications? It seems like
(FTYPE (FUNCTION (INTEGER &OPTIONAL INTEGER) FLOAT))
would have been reasonable, but I can't find anything that suggests
I can do this. &REST would be more complicated, but not prohibitively so.
Am I missing something or do we not have a way to do this at all.
Do we provide a way to declare that a function is n-ary (or not) at all? That
is, the equivalent of the *EXPR and *LEXPR declarations in Maclisp? I guess
I would be surprised if there was no CL implementation that could generate
better code in cases where I declared this kind of thing ahead of time.
And while we're on the subject, is there some reason that PROCLAIM was
not made to be n-ary? It has bothered me on numerous occassions that I
have to do:
(PROCLAIM '(SPECIAL X))
(PROCLAIM '(FIXNUM X))
when we could just as well have allowed:
(PROCLAIM '(SPECIAL X) '(FIXNUM X))
Allowing multiple arguments would be more consistent with DECLARE.
∂11-Mar-86 1542 RAM@C.CS.CMU.EDU Which package...
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 11 Mar 86 15:42:04 PST
Received: ID <RAM@C.CS.CMU.EDU>; Tue 11 Mar 86 18:42:49-EST
Date: Tue, 11 Mar 1986 18:42 EST
Message-ID: <RAM.12189955006.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Which package...
There is a point which I think is being missed in this package
discussion. The default package environment, isn't just a programming
issue; it is also an environment issue. I believe that there should
be some portable way for a program to get the default programming
environment. If there isn't, then many otherwise portable programs
will be modified to use the local version of the default
environment.
The Spice Lisp debugger has various commands and functions
associated with it which are packaged symbols. When I implement a
portable system, I am going to set up the package environment so that
I can use the debugger. If I can't say this in a portable way, then I
will have to edit the sources before every release or maintain a site
dependent file which does the package setup. When another site uses
the system, it is likely that they will edit it again so that they can
use their debugger. This is a totally gratuitous system dependency.
Rob
∂11-Mar-86 1707 MMcM@ALLEGHENY.SCRC.Symbolics.COM TRUE, FALSE
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 11 Mar 86 17:06:49 PST
Received: from OWL.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 4186; Tue 11-Mar-86 20:06:25-EST
Date: Tue, 11 Mar 86 20:03 EST
From: Mike McMahon <MMcM@SCRC-STONY-BROOK.ARPA>
Subject: TRUE, FALSE
To: Guy Steele <gls@THINK-AQUINAS.ARPA>
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <860311105957.5.GLS@GUIDO.THINK.COM>
Message-ID: <860311200354.4.MMCM@OWL.SCRC.Symbolics.COM>
Guy's proposed function cannot be used with special forms (macros) that
take something to be "evaluated in the function context", such as for
example the :print-function option to defstruct. My experience shows
TRUE and FALSE ideally suited for such applications.
∂11-Mar-86 1752 GJC@MC.LCS.MIT.EDU common lisp motto
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 11 Mar 86 17:52:11 PST
Date: Tue, 11 Mar 86 20:52:52 EST
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Subject: common lisp motto
To: RPG@SU-AI.ARPA
cc: common-lisp@SU-AI.ARPA
In-reply-to: Msg of 11 Mar 86 0918 PST from Dick Gabriel <RPG at SU-AI.ARPA>
Message-ID: <[MC.LCS.MIT.EDU].847577.860311.GJC>
Isnt that rather "Why use head when mold will do?"
∂12-Mar-86 0725 gls@THINK-AQUINAS.ARPA Some notes about declarations
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 12 Mar 86 07:24:53 PST
Received: from guido by GODOT.THINK.COM via CHAOS; Wed, 12 Mar 86 10:25:13 est
Date: Wed, 12 Mar 86 10:27 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Some notes about declarations
To: KMP@SCRC-STONY-BROOK.ARPA, Common-Lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <860311174837.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-Id: <860312102727.1.GLS@GUIDO.THINK.COM>
Date: Tue, 11 Mar 86 17:48 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Do we provide a way to type-declare functions (ie, FTYPE) that have
&optional or &rest specifications? It seems like
(FTYPE (FUNCTION (INTEGER &OPTIONAL INTEGER) FLOAT))
would have been reasonable, but I can't find anything that suggests
I can do this. &REST would be more complicated, but not prohibitively so.
Am I missing something or do we not have a way to do this at all.
CLtL, page 47, 4 lines from bottom, make the offhand remark that the
&optional, &rest, and &key markers may appear in the list of argument
types, but unfortunately that bagbiter Steele failed to give any
examples. Furthermore, &allow-other-keys ought to be allowed, because
that has an effect on the external user interface.
I believe this issue has been discussed before on this mailing list.
One problem is that for an &optional argument one can give just the type,
but for a &key argument one must write the keyword as well as the type,
as (:start (integer 0 ())), for example.
Do we provide a way to declare that a function is n-ary (or not) at all? That
is, the equivalent of the *EXPR and *LEXPR declarations in Maclisp? I guess
I would be surprised if there was no CL implementation that could generate
better code in cases where I declared this kind of thing ahead of time.
Sure: to make it n-ary, say
(DECLARE (FTYPE (FUNCTION (&REST T) T) APPEND))
to declare APPEND, for example.
And while we're on the subject, is there some reason that PROCLAIM was
not made to be n-ary? It has bothered me on numerous occassions that I
have to do:
(PROCLAIM '(SPECIAL X))
(PROCLAIM '(FIXNUM X))
when we could just as well have allowed:
(PROCLAIM '(SPECIAL X) '(FIXNUM X))
Allowing multiple arguments would be more consistent with DECLARE.
No reason I know of.
--Guy
∂12-Mar-86 0732 gls@THINK-AQUINAS.ARPA TRUE, FALSE
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 12 Mar 86 07:31:59 PST
Received: from guido by GODOT.THINK.COM via CHAOS; Wed, 12 Mar 86 10:32:27 est
Date: Wed, 12 Mar 86 10:34 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: TRUE, FALSE
To: MMcM@SCRC-STONY-BROOK.ARPA, gls@THINK-AQUINAS.ARPA
Cc: Common-Lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA
In-Reply-To: <860311200354.4.MMCM@OWL.SCRC.Symbolics.COM>
Message-Id: <860312103442.2.GLS@GUIDO.THINK.COM>
Date: Tue, 11 Mar 86 20:03 EST
From: Mike McMahon <MMcM@SCRC-STONY-BROOK.ARPA>
Guy's proposed function cannot be used with special forms (macros) that
take something to be "evaluated in the function context", such as for
example the :print-function option to defstruct. My experience shows
TRUE and FALSE ideally suited for such applications.
[I am now putting on my SCHEME hat.] This is merely another example of
how awkward it is to have distinguished "function contexts" and "value
contexts" when using functionals.
I agree now that TRUE and FALSE may be better suited to the Common lisp
style than CONSTFN (but that style is sometimes awkward).
--Guy
∂12-Mar-86 1102 berman@isi-vaxa.ARPA Validation Contributors
Received: from ISI-VAXA.ARPA by SU-AI.ARPA with TCP; 12 Mar 86 11:02:03 PST
Received: by isi-vaxa.ARPA (4.12/4.7)
id AA05540; Wed, 12 Mar 86 11:02:47 pst
From: berman@isi-vaxa.ARPA (Richard Berman)
Message-Id: <8603121902.AA05540@isi-vaxa.ARPA>
Date: 12 Mar 1986 1102-PST (Wednesday)
To: Common-Lisp@Su-Ai.Arpa
Cc:
Subject: Validation Contributors
ISI is gonna be ramping up the long-awaited supported. The first part of this
is to begin gathering the validation programs promised in the meeting late
last year, and to figure out what areas are not covered and assign them to the
willing.
I'll be contacting the people who had an interest directly. In the meantime,
any general data regarding validations, willingness to help, etc. should be
sent to me.
Thanks a whole heck of a lot.
RB
∂12-Mar-86 1129 DLW@ALLEGHENY.SCRC.Symbolics.COM Having lots of packages with extensions.
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 12 Mar 86 11:29:31 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 4400; Wed 12-Mar-86 13:19:01-EST
Date: Wed, 12 Mar 86 13:18 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Having lots of packages with extensions.
To: greek%bach.decnet@hudson.dec.com, common-lisp@SU-AI.ARPA
In-Reply-To: The message of 11 Mar 86 12:34-EST from "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Message-ID: <860312131836.0.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: 11 Mar 86 12:34:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
I sure
feel uncomfortable, however, if we don't at least say that all those
extra packages follow some naming convention, like SYSTEM-xxx.
Otherwise a layered product simply does not know what names it can use
for its packages.
I have traversed this road before. This doesn't work, because there is
no such thing as a "system/user" distinction in a Lisp environment.
There are many levels, and levels built on levels; there's no line
between what is the "system" and what isn't. I've seen what happens
when you introduce such a convention: every user who produces a package
that's part of a substrate names it SYSTEM-XXX, so that "user" packages
can be built on it. This is definitely the problem of conflict of package
names, but after seeing the same thing on many systems in many contexts,
I am convinced that there's no straightforward and satisfactory solution.
Furthermore, if we say that there can be arbitrary packages with
extensions, then what the hell are we bothering to define the SYSTEM
package for?
Good question. I think it's a special-case solution to a tiny bit of
the problem of conflicting package names, akin to attacking an elephant
with a BB gun, by making one reserved package name for each CL implementation.
Maybe there's a better reason and I can't reconstruct it.
∂12-Mar-86 1407 JAR@MC.LCS.MIT.EDU Which package...
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 12 Mar 86 14:07:21 PST
Date: Wed, 12 Mar 86 17:08:03 EST
From: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
Subject: Which package...
To: RAM@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA
In-reply-to: Msg of Tue 11 Mar 1986 18:42 EST from Rob MacLachlan <RAM at C.CS.CMU.EDU>
Message-ID: <[MC.LCS.MIT.EDU].848564.860312.JAR>
Date: Tue, 11 Mar 1986 18:42 EST
From: Rob MacLachlan <RAM at C.CS.CMU.EDU>
The Spice Lisp debugger has various commands and functions
associated with it which are packaged symbols. When I implement a
portable system, I am going to set up the package environment so that
I can use the debugger. If I can't say this in a portable way, then I
will have to edit the sources before every release or maintain a site
dependent file which does the package setup. When another site uses
the system, it is likely that they will edit it again so that they can
use their debugger. This is a totally gratuitous system dependency.
A design technique I particularly like for getting around
context-sensitivity of this sort is to make the user interface commands
(debug, trace, edit, logout, etc.) accessible through a mechanism other
than the traditional READ + EVAL interface. In liberating a user
interface from READ, it can be made useful even when the current package
doesn't use LISP or USER (a situation I often work with). By the same
token (so to speak), a separate command namespace makes short command
names possible without risk of conflict with user variables - e.g. E for
edit, Q for quit, etc.
An example of this kind of interface (which I admit has myriad problems,
but none which couldn't be fixed) is Symbolics' "command processor,"
which I usually use in the mode where user input is normally parsed as
s-expression, but user input which begins with a colon is parsed as a
carriage-return-terminated "command" of some sort. (Note that colon is
NOT a read macro.)
I don't want to argue the benefits of this paricular interface -
zillions of other syles are possible - I just want to argue against the
importance of the READ-EVAL status quo. It seems inappropriate to argue
against an important language feature for promoting robustness and
portability, like a predictable LISP (or defaultly-used) package, on the
grounds that it makes a certain kludgy kind of user interface, which
doesn't work all that well anyhow, not work.
Jonathan
∂12-Mar-86 2212 mcvax!suna.psg.npl.co.uk!jrp@seismo.CSS.GOV Deletion from Mailing list
Received: from SEISMO.CSS.GOV by SU-AI.ARPA with TCP; 12 Mar 86 22:12:31 PST
Return-Path: <mcvax!suna.psg.npl.co.uk!jrp>
Received: from mcvax.UUCP by seismo.CSS.GOV with UUCP; Thu, 13 Mar 86 00:50:37 EST
From: mcvax!suna.psg.npl.co.uk!jrp@seismo.CSS.GOV
Received: by mcvax.uucp; Thu, 13 Mar 86 05:19:31 +0100 (MET)
Received: from nplpsg.uucp by eagle.Ukc.AC.UK with UUCP id a028098;
12 Mar 86 23:14 GMT
Received: from suna (localhost) by suna.psg.npl.co.uk; Thu, 13 Mar 86 22:36:16 GMT
To: common-lisp@su-ai.arpa
Subject: Deletion from Mailing list
Date: 13 Mar 86 22:36:13 GMT (Thu)
Message-Id: <1000.511137373@suna>
Please remove me from the mailing list common-lisp.
Apologies in advance for cluttering the mailing list,
but I can't for the life of me find the owner's name.
Thanks,
John Pavel
∂12-Mar-86 2317 GSB@MC.LCS.MIT.EDU Re: initforms and implicit blocks
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 12 Mar 86 23:16:54 PST
Date: Thu, 13 Mar 86 02:17:42 EST
From: "Glenn S. Burke" <GSB@MC.LCS.MIT.EDU>
Subject: Re: initforms and implicit blocks
To: NGALL@BBNG.ARPA
cc: COMMON-LISP@SU-AI.ARPA, apollo!dfm@UW-BEAVER.ARPA
Message-ID: <[MC.LCS.MIT.EDU].849069.860313.GSB>
A little semantic experiment i did in NIL (i don't know if it is in
the released version) is that
(defun foo (params...) ...)
defines foo to havve a function definition of
(named-lambda foo (params...) ...).
THis is similar but not identical to the named-lambda which had been
on the lispm at some point. Additionally, when applied, that function
is that provides the named block. All the forms for &optional and &key
arguments in the lambda list are evaluated inside of the block.
With the right modularity, this was not at all difficult to put into
both the compiler and the interpreter.
∂13-Mar-86 0013 cfry%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU (LOAD ... :VERBOSE T)
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 13 Mar 86 00:06:42 PST
Received: from MOSCOW-CENTRE.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 13 Mar 86 03:07-EST
Date: Thu, 13 Mar 86 03:06 EST
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
Reply-To: cfry%oz@MIT-MC.ARPA
Subject: (LOAD ... :VERBOSE T)
To: Fahlman@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12189596052.BABYL@C.CS.CMU.EDU>
Message-ID: <860313030645.5.CFRY@MOSCOW-CENTRE.AI.MIT.EDU>
It's too bad we chose those names, because they are confusing. :verbose
isn't very verbose and is not the most verbose of the available options.
I think we followed Maclisp in this. If the world were young, I would
suggest that :verbose print a comment for each item loaded, that the
default be to print just the "Loading FOO ...done." message, and that
there be a :silent keyword when you want to suppress all printout. But
this is probably not important enough to be worht an incompatible
change.
-- Scott
Another possibility is to eliminate the :print arg, and have
:verbose take the values of :silent :file :forms .
I agree with Scott that the default should be to print
something like: "Loading FOO ...done." [my ":file" option]
I can't stand getting the *silent-treatment* for long computations,
as is conventional in UNIX.
∂13-Mar-86 0559 greek%bach.decnet@hudson.dec.com Package Naming Conventions
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 13 Mar 86 05:59:10 PST
Date: 13 Mar 86 08:51:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: Package Naming Conventions
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
I believe that the simplest method of naming packages so that conflicts
do not arise is to require every organization that produces Common LISP
software to prefix their packages with an official (registered)
organization name. This seems unlikely.
Without such an agreement, we have to start coming up with special
cases. In addition to USER and LISP, we invent a SYSTEM package. Then
we start wondering about additional packages shipped with the base
system, such as an editor or debugger or whatever. So maybe we say that
these packages must begin with SYSTEM-, or we say that they can have any
name. Now independent organizations can't be sure they won't step all
over someone else's packages. And so on.
I think we should either all agree that we will support a package naming
convention that someone devises, or we might as well stop talking about
naming conventions.
- Paul
------
∂13-Mar-86 0744 DLW@ALLEGHENY.SCRC.Symbolics.COM (LOAD ... :VERBOSE T)
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 13 Mar 86 07:44:37 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 4716; Thu 13-Mar-86 10:44:22-EST
Date: Thu, 13 Mar 86 10:43 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: (LOAD ... :VERBOSE T)
To: common-lisp@SU-AI.ARPA
In-Reply-To: <860313030645.5.CFRY@MOSCOW-CENTRE.AI.MIT.EDU>
Message-ID: <860313104349.7.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Thu, 13 Mar 86 03:06 EST
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
It's too bad we chose those names, because they are confusing. :verbose
isn't very verbose and is not the most verbose of the available options.
I think we followed Maclisp in this. If the world were young, I would
suggest that :verbose print a comment for each item loaded, that the
default be to print just the "Loading FOO ...done." message, and that
there be a :silent keyword when you want to suppress all printout. But
this is probably not important enough to be worht an incompatible
change.
-- Scott
Another possibility is to eliminate the :print arg, and have
:verbose take the values of :silent :file :forms .
I agree with Scott that the default should be to print
something like: "Loading FOO ...done." [my ":file" option]
I can't stand getting the *silent-treatment* for long computations,
as is conventional in UNIX.
In our programming environment, we have other ways to tell the user how
far along a computation has gotten than to type out on standard output.
These ways involve graphics and text in other windows. (Some of what I
am referring to is software that will be in the next release, also.)
The point is that this is a programming environment issue, not a
language issue. We cannot standardize on things like this, and so
Common Lisp should not attempt to address these issues.
The line between language and programming environment is not
razor-sharp, and certainly "load" falls in the gray zone. But let's be
quick to realize when it is that we are debating programming environment
issues, and let's admit that there is no way that Common Lisp can do a
satisfactory job in this area, rather than letting Common Lisp be drawn
hopelessly further and further into the programming environment world.
∂13-Mar-86 1031 FAHLMAN@C.CS.CMU.EDU (LOAD ... :VERBOSE T)
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 13 Mar 86 10:31:27 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 13 Mar 86 13:30:59-EST
Date: Thu, 13 Mar 1986 13:30 EST
Message-ID: <FAHLMAN.12190422508.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: (LOAD ... :VERBOSE T)
In-reply-to: Msg of 13 Mar 1986 10:43-EST from Daniel L. Weinreb <DLW at SCRC-QUABBIN.ARPA>
I can imagine legitimate reasons for wanting to include a Load operation,
with appropriate switches, into portable code, so we ought to at least
provide guidelines for what the various switches do in terms of
verbosity. I don't think it gets to far over into environment-land if
we just indicate something like the following:
1. Load with no switches should not print anything on standard-output.
2. The :verbose switch is intended to print some per-file information
and an indication when the loading is done, but not something for every
form that is loaded.
3. The :print switch is intended to cause the read/eval/print loop's
output to be printed, or if the file is compiled, something for each
form that is loaded.
4. These are only guidelines covering the intent of how these switches
are to be used. Implementations are free to indicate this kind of
information in other ways if that makes sense in their environment.
-- Scott
∂13-Mar-86 1148 DLW@ALLEGHENY.SCRC.Symbolics.COM (LOAD ... :VERBOSE T)
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 13 Mar 86 11:48:15 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 4852; Thu 13-Mar-86 14:47:57-EST
Date: Thu, 13 Mar 86 14:47 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: (LOAD ... :VERBOSE T)
To: Fahlman@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12190422508.BABYL@C.CS.CMU.EDU>
Message-ID: <860313144722.4.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Thu, 13 Mar 1986 13:30 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I can imagine legitimate reasons for wanting to include a Load operation,
with appropriate switches, into portable code, so we ought to at least
provide guidelines for what the various switches do in terms of
verbosity. I don't think it gets to far over into environment-land if
we just indicate something like the following:
I agree completely. This is what we should be talking about, and we
should not venture further into environment-land.
∂13-Mar-86 1446 MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA Packages
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 13 Mar 86 14:46:04 PST
Received: from umass-cs by csnet-relay.csnet id bf26067; 13 Mar 86 17:08 EST
Date: Thu, 13 Mar 86 16:42 EST
From: MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA
To: Common-Lisp@su-ai.ARPA
Subject: Packages
A Truly Portable Common-Lisp program can use
ONLY the LISP package, or one that it has created
itself. If not, then it uses something that is NOT in Common-Lisp,
and therefore would have to be modified to run on a different
machine/system. Thus, I don't see what all the fuss it about.
If you use the DEBUGGER package, then your code is NOT Common-Lisp.
This has been stated before by other people (Gregor, Wienreb),
and I hope it won't need to be stated again.
The problem is your program's package names may conflict with
an already existing one. Common-Lisp seems to have already
provided the solution: Have source
files use a DEFVARiable for all the packages referred to.
The variable can be bound to a package that has a non-conflicting
name for any given implementation. However, now you can only
refer to symbols in another package that have been Imported, since
you can't use a package prefix on a symbol, but once code is
ready for Porting, conflicts within the program would be known,
and there would be no need for prefixing. During development,
you would know the name of the package.
Kelly Murray
∂13-Mar-86 1537 KMP@SCRC-STONY-BROOK.ARPA (DELETE ... :COUNT NIL)
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 13 Mar 86 15:36:51 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 437344; Thu 13-Mar-86 15:52:39-EST
Date: Thu, 13 Mar 86 15:52 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: (DELETE ... :COUNT NIL)
To: Common-Lisp@SU-AI.ARPA
Message-ID: <860313155229.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I cannot find any place in CLtL where it specifies what will happen if you
try to do:
(DELETE thing list :COUNT NIL)
The discussion of keywords on p62 suggests that keywords get initialized to
NIL if not supplied.
On p254, the notation used to describe DELETE is ambiguous. Because the
syntax is described as
DELETE @i(item) @i(sequence) &key :from-end :test ...
and not
DELETE @i(item) @i(sequence) &key from-end test ...
it's hard to tell whether the author meant to imply that these keywords would
default to NIL if unsupplied or whether there might be initial values that
he wasn't telling us about.
From experience, I have learned to distrust the initializations of &optional
and &key variables because they frequently lead to confusion. That is, if you
tell someone "the stream is optional and defaults to standard output", they
still can't tell without constructing an experiment whether you mean:
(DEFUN FOO (&OPTIONAL STREAM ...)
(IF (NOT STREAM) (SETQ STREAM *STANDARD-OUTPUT*))
...)
or (DEFUN FOO (&OPTIONAL (STREAM *STANDARD-OUTPUT*) ...)
...)
The latter may seem to be implied, but in my experience, the former
implementation is much more robust since it allows one to simply write
NIL when they only want to specify a later variable. eg, if I only want
to supply a second argument of 3, I can write:
(FOO NIL 3)
to match the first implementation, but must write:
(FOO *STANDARD-OUTPUT* 3)
if the implementation is the second. In cases where the default is computed
in some hairy and/or private way, the situation complicates considerably.
Sometimes, the actual implementation may even have been driven by irrelevant
issues like whether the arglist was `getting too cluttered' and the writer
may have just taken the initialization down in the body to `pretty
things up' without really thinking out what the semantic effect of that
change would be.
The argument for &KEY is similar. It may turn out that you want to define
a function DELQ as per Maclisp. Two possible implementations present themselves:
(DEFUN DELQ (THING LIST &OPTIONAL COUNT)
(DELETE THING LIST :TEST #'EQ :COUNT COUNT))
and
(DEFUN DELQ (THING LIST &OPTIONAL (COUNT NIL COUNT-P))
(APPLY #'DELETE THING LIST :TEST #'EQ (IF COUNT-P (LIST :COUNT COUNT) '())))
Personally, I think the former is more perspicuous, but it can only be written
if we define that it is acceptable for DELETE to take a :COUNT argument of NIL.
If the definition of DELETE is left as vague as it is now, only the second
implementation of DELQ above will be portable.
This issue is obviously more general than just DELETE.
My conclusions from all this are as follows:
* The manual is simply ambiguous on this point currently and unless someone can
cite a definitive passage, I guess we'll have to resign ourselves to this not
being defined.
* Wherever it is possible to get some concensus, I think we should strive to
make passing a keyword of NIL be the same as not passing a keyword. There
will be cases where this will not be possible, so I am not suggesting that
this be an across the board thing -- but I think it can usefully be handled
on a case-by-case basis. :COUNT, :TEST, and :TEST-NOT keywords are good places
to start, however, since there could be no confusion about whether the NIL
was intended as a valid argument. Things like :VERBOSE would not be candidates
since NIL is already valid as an explicit argument.
* Where there is no concensus, or where we agree that passing a keyworded value
of NIL is different than passing no argument, the manual should clearly indicate
such.
∂13-Mar-86 1654 NGALL@G.BBN.COM Re: (DELETE ... :COUNT NIL)
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 13 Mar 86 16:53:45 PST
Date: 13 Mar 1986 19:51-EST
Sender: NGALL@G.BBN.COM
Subject: Re: (DELETE ... :COUNT NIL)
From: NGALL@G.BBN.COM
To: KMP@SCRC-STONY-BROOK.ARPA
Cc: Common-Lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]13-Mar-86 19:51:02.NGALL>
In-Reply-To: <860313155229.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Thu, 13 Mar 86 15:52 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
To: Common-Lisp@SU-AI.ARPA
Subject: (DELETE ... :COUNT NIL)
Message-ID: <860313155229.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I cannot find any place in CLtL where it specifies what will happen if you
try to do:
(DELETE thing list :COUNT NIL)
Cf. pg 247, first para.
The discussion of keywords on p62 suggests that keywords get initialized to
NIL if not supplied.
I assume you mean "if [an initform is] not supplied."
On p254, the notation used to describe DELETE is ambiguous. Because the
syntax is described as
DELETE @i(item) @i(sequence) &key :from-end :test ...
and not
DELETE @i(item) @i(sequence) &key from-end test ...
it's hard to tell whether the author meant to imply that these keywords would
default to NIL if unsupplied or whether there might be initial values that
he wasn't telling us about.
I don't understand why the colon-prefix makes a difference. The
default value for :from-end is nil (cf. pg 246). The default value for
:test is EQL (or maybe #'EQL, cf. pg 245).
From experience, I have learned to distrust the initializations of &optional
and &key variables because they frequently lead to confusion. That is, if you
tell someone "the stream is optional and defaults to standard output", they
still can't tell without constructing an experiment whether you mean:
(DEFUN FOO (&OPTIONAL STREAM ...)
(IF (NOT STREAM) (SETQ STREAM *STANDARD-OUTPUT*))
...)
or (DEFUN FOO (&OPTIONAL (STREAM *STANDARD-OUTPUT*) ...)
...)
The latter may seem to be implied, but in my experience, the former
implementation is much more robust since it allows one to simply write
NIL when they only want to specify a later variable. eg, if I only want
to supply a second argument of 3, I can write:
(FOO NIL 3)
to match the first implementation, but must write:
(FOO *STANDARD-OUTPUT* 3)
if the implementation is the second. In cases where the default is computed
in some hairy and/or private way, the situation complicates considerably.
The right thing to do is to say "if the STREAM is unsupplied or NIL it
defaults to the value of the special variable *standard-input*" (cf.
pg 374). This can be implemented with
(defun foo (&optional (stream nil))
(setf stream (or stream *standard-output*))...)
Sometimes, the actual implementation may even have been driven by irrelevant
issues like whether the arglist was `getting too cluttered' and the writer
may have just taken the initialization down in the body to `pretty
things up' without really thinking out what the semantic effect of that
change would be.
The argument for &KEY is similar. It may turn out that you want to define
a function DELQ as per Maclisp. Two possible implementations present themselves:
(DEFUN DELQ (THING LIST &OPTIONAL COUNT)
(DELETE THING LIST :TEST #'EQ :COUNT COUNT))
and
(DEFUN DELQ (THING LIST &OPTIONAL (COUNT NIL COUNT-P))
(APPLY #'DELETE THING LIST :TEST #'EQ (IF COUNT-P (LIST :COUNT COUNT) '())))
Is this perspicuous enough?
(defun delq (thing list &optional (count nil))
(delete thing list :test #'eq :count (or count (length list))))
Personally, I think the former is more perspicuous, but it can only be written
if we define that it is acceptable for DELETE to take a :COUNT argument of NIL.
If the definition of DELETE is left as vague as it is now, only the second
implementation of DELQ above will be portable.
See above.
This issue is obviously more general than just DELETE.
My conclusions from all this are as follows:
* The manual is simply ambiguous on this point currently and unless someone can
cite a definitive passage, I guess we'll have to resign ourselves to this not
being defined.
See above passage.
* Wherever it is possible to get some concensus, I think we should strive to
make passing a keyword of NIL be the same as not passing a keyword. There
will be cases where this will not be possible, so I am not suggesting that
this be an across the board thing -- but I think it can usefully be handled
on a case-by-case basis. :COUNT, :TEST, and :TEST-NOT keywords are good places
to start, however, since there could be no confusion about whether the NIL
was intended as a valid argument. Things like :VERBOSE would not be candidates
since NIL is already valid as an explicit argument.
I think this is the current consensus. I think that all keywords for
which NIL is an invalid argument are documented as "if supplied and
not NIL" (i.e., supplying NIL is equiv. to not supplying the keyword
arg). Two exceptions are :test and :test-not. This should be
clarified on page 246.
* Where there is no concensus, or where we agree that passing a keyworded value
of NIL is different than passing no argument, the manual should clearly indicate
such.
The manual should always clearly state what the default for a keyword is.
-- Nick
∂13-Mar-86 1715 Moon@ALLEGHENY.SCRC.Symbolics.COM Re: (DELETE ... :COUNT NIL)
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 13 Mar 86 17:12:28 PST
Received: from LONG-TAILED-JAEGER.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 5012; Thu 13-Mar-86 20:12:02-EST
Date: Thu, 13 Mar 86 20:14 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Re: (DELETE ... :COUNT NIL)
To: NGALL@G.BBN.COM
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <[G.BBN.COM]13-Mar-86 19:51:02.NGALL>
Message-ID: <860313201417.4.MOON@LONG-TAILED-JAEGER.SCRC.Symbolics.COM>
Date: 13 Mar 1986 19:51-EST
From: NGALL@G.BBN.COM
Date: Thu, 13 Mar 86 15:52 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
I cannot find any place in CLtL where it specifies what will happen if you
try to do:
(DELETE thing list :COUNT NIL)
Cf. pg 247, first para.
So the only actual problem is that the definition of the arguments to DELETE is not
in the section of the manual that purports to describe DELETE. Good, I wish all
language issues were disposed of this easily!
∂13-Mar-86 2259 GSB@MC.LCS.MIT.EDU -*- lines
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 13 Mar 86 22:58:47 PST
Date: Fri, 14 Mar 86 01:59:39 EST
From: "Glenn S. Burke" <GSB@MC.LCS.MIT.EDU>
Subject: -*- lines
To: common-lisp@SU-AI.ARPA
Message-ID: <[MC.LCS.MIT.EDU].850353.860314.GSB>
I found these especially useful in Maclisp where the parsiing had to
be done in Teco.
I'm not going to bother to explain all the references, but for those
who know already, i did a file attribute list frob for LSB which
(redundantly) specified the module and system, and the use of an LSB
file attribumte list option was useful for both incremnetal
compilation on the lispm and for getting things read into Maclisp via
LEDIT in the correct readtable.
I just looked at the creation date of the latest such hacked ledit
file i use, and it was in 1980. I was a bit surprised by the age...
It's still being used.
∂14-Mar-86 0432 GJC@MC.LCS.MIT.EDU Package Naming Conventions
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 14 Mar 86 04:32:43 PST
Date: Fri, 14 Mar 86 07:33:35 EST
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Subject: Package Naming Conventions
To: greek%bach.decnet@HUDSON.DEC.COM
cc: common-lisp@SU-AI.ARPA
In-reply-to: Msg of 13 Mar 86 08:51:00 EST from BACH::GREEK <greek%bach.decnet at hudson.dec.com>
Message-ID: <[MC.LCS.MIT.EDU].850474.860314.GJC>
From time to time I have had to deal with 3 programs that were in the
COMPILER package. Obviously all three were compilers. One was lispmachine
native, and the other two cross compilers. In the LMI software, and most likely
in the TI and Symbolics too by pedigree, the package NAME space is
potentially nested, so you can set up packages that shadow other package
names. Then package names can be used a bit more like one uses directory
names in an operating system, it makes sense to nest them, FOO:BAR:BAZ:SYMBOL.
(Search rules and ACLS anyone?)
You probably want to introduce such a feature into your system, so then
at least users will be able to port code without package name conflicts.
Look at the bright side, at least on a VAX you can run more than one
lisp environment at the same time on the same machine.
-gjc
∂14-Mar-86 0445 GJC@MC.LCS.MIT.EDU How many name spaces in CL?
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 14 Mar 86 04:45:24 PST
Date: Fri, 14 Mar 86 07:46:13 EST
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Subject: How many name spaces in CL?
To: gls@AQUINAS.THINK.COM
cc: Common-Lisp@SU-AI.ARPA
In-reply-to: Msg of Wed 12 Mar 86 10:27 EST from Guy Steele <gls at THINK-AQUINAS.ARPA>
Message-ID: <[MC.LCS.MIT.EDU].850498.860314.GJC>
I've been trying to come up with a complete list of name spaces in CL.
So far I have:
0. SPECIAL FORM
1. lexical bound function, e.g. FLET
2. global function, SYMBOL-FUNCTION, presumably DEFUN?
3. lexical value. LET, SETQ.
4. fluid value. LET, SETQ, semantics overloaded via special declaration.
5. GO TAGBODY
6. BLOCK NAME
7. CATCH TAG
8. TYPE SPECIFIER
9. PACKAGE NAME
Did I leave any out? It might be nice to have a table of these in the CL
manual. Columns with entries for the binding and setting constructs,
or an "X" if no construct.
With so many name spaces already it is unfortnate there is no
construct for defining new name spaces.
∂14-Mar-86 0558 RAM@C.CS.CMU.EDU Packages
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 14 Mar 86 05:58:39 PST
Received: ID <RAM@C.CS.CMU.EDU>; Fri 14 Mar 86 08:58:33-EST
Date: Fri, 14 Mar 1986 08:58 EST
Message-ID: <RAM.12190635075.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA
Cc: Common-Lisp@SU-AI.ARPA
Subject: Packages
Date: Thursday, 13 March 1986 16:42-EST
From: MURRAY%umass-cs.csnet at CSNET-RELAY.ARPA
To: Common-Lisp at su-ai.ARPA
Re: Packages
A Truly Portable Common-Lisp program can use
ONLY the LISP package, or one that it has created
itself. If not, then it uses something that is NOT in Common-Lisp,
and therefore would have to be modified to run on a different
machine/system. Thus, I don't see what all the fuss it about.
If you use the DEBUGGER package, then your code is NOT Common-Lisp.
This has been stated before by other people (Gregor, Wienreb),
and I hope it won't need to be stated again.
Untrue, or at least not proven. Using a package doesn't imply that
any symbols from that package are used in code. Why would you use a
package when you don't use any of the symbols? My answer is that some
symbols may be part of the programming environment rather than part of
code. My program doesn't call debug:backtrace, but I do. I am
therefore not portable, but this has no direct effect on my program.
JAR suggests that this problem can be avoided by not using Lisp
symbols in the user interface. This may be a good idea, but it is not
obvious to me that Common Lisp should make impossible reasonable user
interfaces which do use symbols.
Interestingly, DCP says:
Personally, I always specify a default for MAKE-PACKAGE :USE. That's
probably because our default is to :USE only LISP, which I think is the
right thing. :USE'ing any other packages would lead to name conflicts
KMP is trying to avoid.
This leads me to conclude that he never writes a portable program, since he
always explicitly mentions non-Common Lisp packages in his :USE lists.
Rob
∂14-Mar-86 0751 FAHLMAN@C.CS.CMU.EDU How many name spaces in CL?
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 14 Mar 86 07:48:11 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 14 Mar 86 10:48:08-EST
Date: Fri, 14 Mar 1986 10:48 EST
Message-ID: <FAHLMAN.12190655018.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Cc: Common-Lisp@SU-AI.ARPA
Subject: How many name spaces in CL?
In-reply-to: Msg of 14 Mar 1986 07:46-EST from George J. Carrette <GJC at MC.LCS.MIT.EDU>
WHy would anyone want to enumerate this set? There are a bunch of
obvious members, and then they get kind of arguable and trail off into
infinity.
With so many name spaces already it is unfortnate there is no
construct for defining new name spaces.
There are several such mechanisms: hashtables, property lists, macros...
it all depends on how you choose to look at the result.
-- Scott
∂17-Mar-86 0124 cfry%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU How many name spaces in CL?
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 17 Mar 86 01:23:19 PST
Received: from DUANE.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 17 Mar 86 04:15-EST
Date: Mon, 17 Mar 86 04:14 EST
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
Reply-To: cfry%oz@MIT-MC.ARPA
Subject: How many name spaces in CL?
To: Fahlman@C.CS.CMU.EDU, GJC@MIT-MC.ARPA
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12190655018.BABYL@C.CS.CMU.EDU>
Message-ID: <860317041432.3.CFRY@DUANE.AI.MIT.EDU>
Received: from MC.LCS.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 14 Mar 86 11:15-EST
Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 14 Mar 86 11:14:01 EST
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 14 Mar 86 07:48:11 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 14 Mar 86 10:48:08-EST
Date: Fri, 14 Mar 1986 10:48 EST
Message-ID: <FAHLMAN.12190655018.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Cc: Common-Lisp@SU-AI.ARPA
Subject: How many name spaces in CL?
In-reply-to: Msg of 14 Mar 1986 07:46-EST from George J. Carrette <GJC at MC.LCS.MIT.EDU>
WHy would anyone want to enumerate this set? There are a bunch of
obvious members, and then they get kind of arguable and trail off into
infinity.
I've thought about such a list myself. A list of namespaces is a concise, useful
viewpoint of CL. Thank you GJC for making it for us. I hope it will appear
in the next CLtL.
With so many name spaces already it is unfortnate there is no
construct for defining new name spaces.
There are several such mechanisms: hashtables, property lists, macros...
it all depends on how you choose to look at the result.
A mechanism for defining namespaces has some interesting possibilities.
First, the list that GJC constructed by hand could have been created automatically
by the def-namespace form. If for no other reason than documentation, its useful.
Next, I can imagine an apropos which takes a list of namespaces to search through.
I'll be suprised if there aren't other uses, though I wouldn't want to
jump into making such a mechanism part of CL.
Scott raises the issue that every plist or random alist is,
in effect, a separate namespace. This is true for one definition of namespace.
But at least some of the namespaces that GJC was using
have the characteristic that each namespace contained only and all objects of a type.
Such is not true for random data structures.
Maybe this property can be exploited for a general gain in power
similarly to deftype?
∂17-Mar-86 0841 shebs%utah-orion@utah-cs.arpa Namespaces
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 17 Mar 86 08:41:34 PST
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA16499; Mon, 17 Mar 86 09:43:59 MST
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA06716; Mon, 17 Mar 86 09:43:56 MST
Date: Mon, 17 Mar 86 09:43:56 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8603171643.AA06716@utah-orion.ARPA>
To: common-lisp@su-ai.arpa
Subject: Namespaces
While the idea of defining namespaces is intriguing, I don't think we're
in a position to try to standardize on it. The notion of "namespace"
is pretty informal - we talk about namespaces for variables, for functions,
for packages, etc. But recall that separate namespaces for variables
and functions implies that symbol-function and symbol-value are different,
plus we have an flet in addition to let, as well as a great many other
consequences. Being able to define new namespaces and attach interesting
semantics to them is tantamount to being able to make an implementation
switch from Common Lisp to Scheme and back at the tweak of a flag. I haven't
seen anybody do this! (although it would make an interesting paper).
So since namespace definition is a fairly heavy-duty research issue,
we shouldn't try to standardize on it, unless someone has an absolutely
brilliant proposal...
stan
∂17-Mar-86 1935 FAHLMAN@C.CS.CMU.EDU Committee Membership for ANSI/ISO
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 17 Mar 86 19:34:59 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 17 Mar 86 22:37:05-EST
Date: Mon, 17 Mar 1986 22:37 EST
Message-ID: <FAHLMAN.12191570517.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Committee Membership for ANSI/ISO
At the December Common Lisp meeting Scott Fahlman, Dick Gabriel, Bob
Mathis, Dave Moon, Stephen Squires, Guy Steele, and Dan Weinreb were
charged with the duty of selecting a technical committee and a steering
committee to develop ANSI and ISO standards for Common Lisp. This
message is to report on the membership of those committees, to describe
the actions we have taken towards making those committees official, and
to outline the next steps we need to take.
We have decided not to create the committee under DARPA sponsorship, but
rather to operate within the ANSI framework, setting up a committee for
Common Lisp under X3 tentatively known as X3J13.
The membership in X3J13 will be self-selecting: X3 committees are open
to anyone who pays the dues ($150/year) and who participates actively in
the committee's work. These organizations move very slowly: X3J13
cannot begin operating until next fall at the earliest. Once the X3J13
committee is functioning, the technical and steering committees will
report to X3J13. In the meantime, we expect to make considerable
progress toward producing an acceptable standard.
X3 committees are permitted to have members from other countries. We
have not asked anyone outside the U. S. to join either committee as yet,
but we intend to invite some members from outside the U. S. as a way of
getting the benefit of international experience and cooperation.
There are two committees that we propose to establish now: the steering
committee and the technical committee. The steering committee is
charged with guiding the results of the technical committee through the
standardization process, particularly at the ISO level. The technical
committee is to refine the language definition and produce a document
specifying the proposed Common Lisp standard.
The American members of the steering committee are:
Richard P. Gabriel, Lucid, Inc.
Robert F. Mathis, Private Consultant
John McCarthy, Stanford University
Ronald Ohlander, USC Information Sciences Institute
Stephen L. Squires, Defense Advanced Research Projects Agency
Guy L. Steele Jr., Thinking Machines, Inc.
The American members of the technical committee were chosen according to
several criteria:
(1) The member must have a deep knowledge of Lisp, with experience both
in the implementation and design of at least one serious Lisp
implementation.
(2) The member must be a well-recognized, prominent individual. He or she
must be someone whose reputation is recognized internationally.
(3) The group, considered as a whole, must reflect the wide variety of
viewpoints and backgrounds that are present in the Common Lisp
community.
(4) The committee must not be so large that it is unable to reach
decisions with reasonable speed.
(5) The members are chosen as individuals with a commitment to the
success of Common Lisp as a widely used standard, and not as
representatives of their respective companies or organizations.
Obviously, if the committee is to be of reasonable size, it is not
possible for every company and implementation group to be represented on
the technical committee. Our intention is to discuss each issue as it
arises on the Common Lisp mailing list and to invite any interested
individuals to observe and participate in this discussion. The technical
committee will be responsible for making final decisions on what will go
into the proposed Common Lisp document, but no final decisions will be
made without ample opportunity for input from the whole community. Some
disagreement is probably inevitable, but there will be no surprises.
While the opinion of each individual will be considered, companies may
wish to appoint an official spokesperson who is authorized to speak for
the company in technical matters. We will attempt to arrange for
netmail access for one person from any serious implementation group that
does not currently enjoy such access.
The American members of the technical committee are:
Alan Bawden, Massachusetts Institute of Technology
Daniel G. Bobrow, Xerox Corporation
Scott E. Fahlman, Carnegie-Mellon University
Richard P. Gabriel, Lucid, Inc.
Martin L. Griss, Hewlett-Packard, Inc.
David A. Moon, Symbolics, Inc.
Jonathan A. Rees, Massachusetts Institute of Technology
Guy L. Steele Jr., Thinking Machines, Inc.
At this point a document has been submitted to the Standards Planning and
Requirements Committee of X3, known as SPARC, proposing the formation of
the X3J13 committee. SPARC is the committee which must approve the
formation of any new technical committees. The document outlines the need
for such a committee, the scope of the standard, the potential members of
the committee, and the plan and schedule for accomplishing the standard.
We hope that the standardization work informally started in the Lisp community
will continue to fruition at the national and international levels.
Scott E. Fahlman
Richard P. Gabriel
Robert F. Mathis
David A. Moon
Guy L. Steele Jr.
Stephen L. Squires
Daniel L. Weinreb
∂17-Mar-86 2126 RPG Error handling proposal
To: common-lisp@SU-AI.ARPA
The file is:
CLERR.PRP[COM,LSP]
and can be FTPed without login.
-rpg-
∂18-Mar-86 0710 gls@THINK-AQUINAS.ARPA [CAL@THINK-AQUINAS.ARPA: packages and common lisp (yuk)]
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 18 Mar 86 07:10:49 PST
Received: from ubaldo by GODOT.THINK.COM via CHAOS; Tue, 18 Mar 86 10:11:29 est
Date: Tue, 18 Mar 86 10:13 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: [CAL@THINK-AQUINAS.ARPA: packages and common lisp (yuk)]
To: common-lisp@SU-AI.ARPA
Cc: cal@THINK-AQUINAS.ARPA
Message-Id: <860318101323.2.GLS@THINK-UBALDO.ARPA>
This may be relevant to Common Lispers:
Date: Mon, 17 Mar 86 20:29 EST
From: Cliff Lasser <CAL@THINK-AQUINAS.ARPA>
Date: Mon, 17 Mar 86 12:55 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Date: Mon, 17 Mar 86 04:52 EST
From: Cliff Lasser <CAL@THINK-AQUINAS.ARPA>
It appears that CL:MAKE-PACKAGE makes it necessary to refer to unexported
symbols of that package as FOO::BAR as opposed to FOO:BAR. Is there anyway
to tell CL that ALL symbols of a package should be exported so that the
behavior is the same as ZL:MAKE-PACKAGE?
Thanx -Cliff
Apparently not. About the best you can do is, at some appropriately
late point, (do-symbols (x pkg) (export x pkg)).
--Guy
UGH
∂18-Mar-86 0729 gls@THINK-AQUINAS.ARPA [ART@THINK-AQUINAS.ARPA: Another reader macro]
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 18 Mar 86 07:29:29 PST
Received: from ubaldo by GODOT.THINK.COM via CHAOS; Tue, 18 Mar 86 10:29:47 est
Date: Tue, 18 Mar 86 10:31 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: [ART@THINK-AQUINAS.ARPA: Another reader macro]
To: common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
Message-Id: <860318103140.4.GLS@THINK-UBALDO.ARPA>
Another true-life story from a real User:
Date: Tue, 18 Mar 86 01:19 EST
From: Art Medlar
I've often had a need to comment out a single s-expression
temporarily. Using a semicolon is reasonable only when the
expression is on one line, and it's really annoying when the
line containing the expression has other things that you don't
want to comment out, like closing parentheses of super-expressions.
#-LISPM would probably work, but it's not intended to be used
this way, and it's too long.
So I wrote the #! reader macro. When placed immediately in front
of a list, it causes the reader to completely ignore the list. It's
a lot like #| |# except it operates over a single s-expression and
so needs no termination symbol. It is more useful than (comment ...)
and (ignore ...) since comment returns the symbol COMMENT and ignore
returns NIL. For example, the following form returns T
(and (minusp -1)
#!(zerop
(+ 4 3))
(plusp 1)
#!(zerop 0))
To get it, load a:>utility>reader-macros. If it doesn't cause any
problems, I'll add it to the system.
--art
∂18-Mar-86 0740 FAHLMAN@C.CS.CMU.EDU [ART@THINK-AQUINAS.ARPA: Another reader macro]
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 18 Mar 86 07:40:38 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 18 Mar 86 10:42:49-EST
Date: Tue, 18 Mar 1986 10:42 EST
Message-ID: <FAHLMAN.12191702634.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Guy Steele <gls@AQUINAS.THINK.COM>
Cc: common-lisp@SU-AI.ARPA
Subject: [ART@THINK-AQUINAS.ARPA: Another reader macro]
In-reply-to: Msg of 18 Mar 1986 10:31-EST from Guy Steele <gls at THINK-AQUINAS.ARPA>
I'd like to see the combination #! be reserved for something more
important and interesting than comment out a single expression. The #|
... |# does this job perfectly well, except that you need to find the
end of the thing you are commenting out: only one or two extra
keystrokes in a decent editor. Is suppose that if doing this as a pure
prefix were deemed useful, we could adopt the convention that the
feature T is always present in all Common Lisps, so that #-T would do
the right thing.
[It's really too bad that some people decided that T and NIL were cute
names for Lisp dialects. Would #-T run afoul of someone's T-language
emulation package?]
-- Scott
∂18-Mar-86 0759 KMP@SCRC-STONY-BROOK.ARPA Error handling proposal
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 18 Mar 86 07:57:46 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 440718; Tue 18-Mar-86 10:40:26-EST
Date: Tue, 18 Mar 86 10:41 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Error handling proposal
To: Common-Lisp@SU-AI.ARPA
In-Reply-To: The message of 18 Mar 86 00:26-EST from Dick Gabriel <RPG@SU-AI.ARPA>
Message-ID: <860318104101.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 17 Mar 86 2126 PST
From: Dick Gabriel <RPG@SU-AI.ARPA>
The file is:
CLERR.PRP[COM,LSP]
and can be FTPed without login.
-rpg-
A word of explanation for those who don't understand what this message is about.
The proposal is going to be discussed on CL-ERROR-HANDLING for now. When it has
reached concensus on that list, it will be moved to the COMMON-LISP list. If
you're not on CL-ERROR-HANDLING and would like to be, send mail to RPG@SU-AI.
Please do not send mail about this to COMMON-LISP for now, since it's a broader
list and some of its recipients may not want to see every detail of the design
process.
Thanks,
-kmp
∂18-Mar-86 1125 Moon@ALLEGHENY.SCRC.Symbolics.COM [ART@THINK-AQUINAS.ARPA: Another reader macro]
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 18 Mar 86 11:25:06 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 6257; Tue 18-Mar-86 14:24:55-EST
Date: Tue, 18 Mar 86 14:23 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: [ART@THINK-AQUINAS.ARPA: Another reader macro]
To: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12191702634.BABYL@C.CS.CMU.EDU>
Message-ID: <860318142305.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 18 Mar 1986 10:42 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I'd like to see the combination #! be reserved for something more
important and interesting than comment out a single expression. The #|
... |# does this job perfectly well, except that you need to find the
end of the thing you are commenting out: only one or two extra
keystrokes in a decent editor. I suppose that if doing this as a pure
prefix were deemed useful, we could adopt the convention that the
feature T is always present in all Common Lisps, so that #-T would do
the right thing.
We typically use #+IGNORE for this, although personally I'm a big fan
of semicolon for comments.
∂18-Mar-86 1137 Moon@ALLEGHENY.SCRC.Symbolics.COM [CAL@THINK-AQUINAS.ARPA: packages and common lisp (yuk)]
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 18 Mar 86 11:37:41 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 6264; Tue 18-Mar-86 14:37:37-EST
Date: Tue, 18 Mar 86 14:35 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: [CAL@THINK-AQUINAS.ARPA: packages and common lisp (yuk)]
To: common-lisp@SU-AI.ARPA, cal@THINK-AQUINAS.ARPA
In-Reply-To: <860318101323.2.GLS@THINK-UBALDO.ARPA>
Message-ID: <860318143541.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 17 Mar 86 04:52 EST
From: Cliff Lasser <CAL@THINK-AQUINAS.ARPA>
It appears that CL:MAKE-PACKAGE makes it necessary to refer to unexported
symbols of that package as FOO::BAR as opposed to FOO:BAR. Is there anyway
to tell CL that ALL symbols of a package should be exported so that the
behavior is the same as ZL:MAKE-PACKAGE?
For the record, Symbolics' implementation includes as extensions the
:EXTERNAL-ONLY (value T or NIL) and :COLON-MODE (value :INTERNAL or :EXTERNAL)
options to MAKE-PACKAGE for this purpose. The former option exports all
symbols, the latter simply causes : to have the same effect as :: .
I don't know whether any other implementations have picked up these ideas.
∂18-Mar-86 1239 preece%ccvaxa@gswd-vms Re: [ART@THINK-AQUINAS.ARPA: Another
Received: from GSWD-VMS.ARPA by SU-AI.ARPA with TCP; 18 Mar 86 12:39:15 PST
Received: from ccvaxa.GSD (ccvaxa.ARPA) by gswd-vms.ARPA (5.9/)
id AA06268; Tue, 18 Mar 86 14:38:14 CST
Message-Id: <8603182038.AA06268@gswd-vms.ARPA>
Date: Tue, 18 Mar 86 14:33:57 cst
From: preece%ccvaxa@gswd-vms (Scott E. Preece)
To: COMMON-LISP@su-ai.arpa
Subject: Re: [ART@THINK-AQUINAS.ARPA: Another
> From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
>
> Date: Tue, 18 Mar 1986 10:42 EST
> From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
>
>
> I'd like to see the combination #! be reserved for something more
> important and interesting than comment out a single expression.
>
> We typically use #+IGNORE for this, although personally I'm a big fan
> of semicolon for comments.
----------
So, why not use "#;", which the book says is undefined? Seems
reasonably mnemonic to make it "ignore s-expression" given that
";" is "ignore-rest-of-line".
--
scott preece
gould/csd - urbana
ihnp4!uiucdcs!ccvaxa!preece
∂18-Mar-86 1343 DCP@ALLEGHENY.SCRC.Symbolics.COM Re: [ART@THINK-AQUINAS.ARPA: Another
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 18 Mar 86 13:40:29 PST
Received: from FIREBIRD.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 6287; Tue 18-Mar-86 16:40:21-EST
Date: Tue, 18 Mar 86 16:39 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: Re: [ART@THINK-AQUINAS.ARPA: Another
To: Scott E. Preece <preece%ccvaxa@GSWD-VMS.ARPA>,
COMMON-LISP@SU-AI.ARPA
In-Reply-To: <8603182038.AA06268@gswd-vms.ARPA>
Message-ID: <860318163930.2.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Tue, 18 Mar 86 14:33:57 cst
From: preece%ccvaxa@gswd-vms (Scott E. Preece)
> From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
>
> Date: Tue, 18 Mar 1986 10:42 EST
> From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
>
>
> I'd like to see the combination #! be reserved for something more
> important and interesting than comment out a single expression.
>
> We typically use #+IGNORE for this, although personally I'm a big fan
> of semicolon for comments.
----------
So, why not use "#;", which the book says is undefined? Seems
reasonably mnemonic to make it "ignore s-expression" given that
";" is "ignore-rest-of-line".
--
scott preece
gould/csd - urbana
ihnp4!uiucdcs!ccvaxa!preece
I don't think this is in the domain of the language, since there is
already a perfectly good way (two actually: ; and #|...|#) to comment
something out. The responses so far have shown that several people have
different ways to accomplish the goal. Mine is #+++ignore (and to put
temporary code in that really shouldn't be there, I use #---ignore <form>)
on the grounds that I can later search for --- and +++ as markers for
things needing attention.
∂18-Mar-86 1439 gls@THINK-AQUINAS.ARPA Re: [ART@THINK-AQUINAS.ARPA: Another
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 18 Mar 86 14:34:06 PST
Received: from ubaldo by GODOT.THINK.COM via CHAOS; Tue, 18 Mar 86 17:34:25 est
Date: Tue, 18 Mar 86 17:36 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Re: [ART@THINK-AQUINAS.ARPA: Another
To: DCP@SCRC-QUABBIN.ARPA, preece%ccvaxa@GSWD-VMS.ARPA, COMMON-LISP@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <860318163930.2.DCP@FIREBIRD.SCRC.Symbolics.COM>
Message-Id: <860318173619.4.GLS@THINK-UBALDO.ARPA>
Date: Tue, 18 Mar 86 16:39 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Date: Tue, 18 Mar 86 14:33:57 cst
From: preece%ccvaxa@gswd-vms (Scott E. Preece)
> From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
> Date: Tue, 18 Mar 1986 10:42 EST
> From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
> I'd like to see the combination #! be reserved for something more
> important and interesting than comment out a single expression.
> We typically use #+IGNORE for this, although personally I'm a big fan
> of semicolon for comments.
----------
So, why not use "#;", which the book says is undefined? Seems
reasonably mnemonic to make it "ignore s-expression" given that
I don't think this is in the domain of the language, since there is
already a perfectly good way (two actually: ; and #|...|#) to comment
something out. The responses so far have shown that several people have
different ways to accomplish the goal....
It seems to me that if several people have independently found it necessary
to invent another way, however crocky, to comment out an s-expression,
then the existing methods are not perfectly good. I too have found ; and
#| inconvenient for this purpose. One reason is that one is forced not
only to insert the comment mark itself but often also one or more newlines.
(cond ((am-i-losing) (try-to-win))
((am-i-winning) #|(try-to-lose)|#)
(t (try-to-try)))
really looks awful, and to use ";" one must do something like
(cond ((am-i-losing) (try-to-win))
((am-i-winning)
;;(try-to-lose)
)
(t (try-to-try)))
[the double semicolon being necessary to make the indentation
conventions of many editors do the right thing]. The problem with
either of these methods, however, is that both ; and #| are forced to
treat their contents as unstructured text, and therefore many editors
cannot deal with editing the code in its commented-out state (it won't
indent properly, etc.). This is the main attraction for me of a standard
way to comment out an s-expression. I am a bit leery of #+ignore or
#+++ignore, because some turkey could make IGNORE or ++IGNORE be a feature
after all and ruin everything; but #+(or) strikes me as an acceptable
idiom (but perhaps #-(and) is better to emphasize its negative nature).
--Guy
∂18-Mar-86 1454 FAHLMAN@C.CS.CMU.EDU [ART@THINK-AQUINAS.ARPA: Another
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 18 Mar 86 14:53:57 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 18 Mar 86 17:56:06-EST
Date: Tue, 18 Mar 1986 17:56 EST
Message-ID: <FAHLMAN.12191781511.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Guy Steele <gls@AQUINAS.THINK.COM>
Cc: COMMON-LISP@SU-AI.ARPA
Subject: [ART@THINK-AQUINAS.ARPA: Another
In-reply-to: Msg of 18 Mar 1986 17:36-EST from Guy Steele <gls at THINK-AQUINAS.ARPA>
I am a bit leery of #+ignore or
#+++ignore, because some turkey could make IGNORE or ++IGNORE be a feature
after all and ruin everything; but #+(or) strikes me as an acceptable
idiom (but perhaps #-(and) is better to emphasize its negative nature).
Feh! This is by far the ugliest and most confusing construct ever
proposed for Common Lisp (not counting Format, of course). I don't
think that this problem needs to be solved, but if it does I find #;
infinitely preferable, even though it wastes a perfectly good macro
character.
-- Scott
∂18-Mar-86 1721 Moon@ALLEGHENY.SCRC.Symbolics.COM Re: [ART@THINK-AQUINAS.ARPA: Another
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 18 Mar 86 17:21:13 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 6407; Tue 18-Mar-86 20:11:33-EST
Date: Tue, 18 Mar 86 20:09 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Re: [ART@THINK-AQUINAS.ARPA: Another
To: Common-Lisp@SU-AI.ARPA
In-Reply-To: <860318173619.4.GLS@THINK-UBALDO.ARPA>
Message-ID: <860318200937.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 18 Mar 86 17:36 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
> Date: Tue, 18 Mar 1986 10:42 EST
> From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
> I'd like to see the combination #! be reserved for something more
> important and interesting than comment out a single expression.
....The problem with
either of these methods, however, is that both ; and #| are forced to
treat their contents as unstructured text, and therefore many editors
cannot deal with editing the code in its commented-out state (it won't
indent properly, etc.).
Our editor uses #|| ... ||# as a way to comment out structured text. This
is just a convention and doesn't involve an actual extension to Common Lisp.
I'm not sure whether editor conventions are properly in the domain of the
Common Lisp language specification, though.
∂18-Mar-86 1812 KMP@SCRC-STONY-BROOK.ARPA [ART@THINK-AQUINAS.ARPA: Another
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 18 Mar 86 18:10:18 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 441580; Tue 18-Mar-86 21:09:02-EST
Date: Tue, 18 Mar 86 21:09 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: [ART@THINK-AQUINAS.ARPA: Another
To: Fahlman@C.CS.CMU.EDU
cc: COMMON-LISP@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12191781511.BABYL@C.CS.CMU.EDU>
Message-ID: <860318210941.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Tue, 18 Mar 1986 17:56 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I am a bit leery of #+ignore or
#+++ignore, because some turkey could make IGNORE or ++IGNORE be a feature
after all and ruin everything; but #+(or) strikes me as an acceptable
idiom (but perhaps #-(and) is better to emphasize its negative nature).
Feh! This is by far the ugliest and most confusing construct ever
proposed for Common Lisp (not counting Format, of course). I don't
think that this problem needs to be solved, but if it does I find #;
infinitely preferable, even though it wastes a perfectly good macro
character.
As a pragmatic issue, some text editors (particularly Emacs) will have trouble
with "#;" because they will think the ";" means comment to end of line and may
not recognize the "#;" as a cluster. While such programs would obviously be in
error, they might not get fixed very quickly and users might suffer as a
consequence. For this reason, I suggest that "#;" be held in reserve and not
used for anything that does not read just a single line of text.
Similar motivation was likely used when we made #|...|# be matchfix -- to
avoid confusion with the fact that |...| by itself is matchfix.
-kmp
∂19-Mar-86 0622 greek%bach.decnet@hudson.dec.com Ignoring a list.
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 19 Mar 86 06:22:38 PST
Date: 19 Mar 86 09:14:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: Ignoring a list.
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
I agree with Scott that this is a fairly absurd discussion (I don't,
however, agree with his editorial comment about FORMAT, which is moaned
about all over but never with an alternative suggestion. [This is not
an editorial comment, of course]).
In the time we've all spent writing about some method of ignoring one
list, we could all have typed many #| ... |# constructs.
- Paul
------
∂19-Mar-86 0713 DCP@ALLEGHENY.SCRC.Symbolics.COM Ignoring a list.
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 19 Mar 86 07:13:33 PST
Received: from FIREBIRD.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 6489; Wed 19-Mar-86 10:13:32-EST
Date: Wed, 19 Mar 86 10:13 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: Ignoring a list.
To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>,
common-lisp <common-lisp@SU-AI.ARPA>
In-Reply-To: The message of 19 Mar 86 09:14-EST from "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Message-ID: <860319101300.8.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: 19 Mar 86 09:14:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
I agree with Scott that this is a fairly absurd discussion (I don't,
however, agree with his editorial comment about FORMAT, which is moaned
about all over but never with an alternative suggestion. [This is not
an editorial comment, of course]).
In the time we've all spent writing about some method of ignoring one
list, we could all have typed many #| ... |# constructs.
That's true. The thing we are dicussing is that you can type 3 or 4
times as many #;, #+IGNORE's, #+++IGNORE's, etc, than you can type
#|...|#. This is because #|...|# requires hacking two places in the
text (before and after the expression). Removing a #+IGNORE to
reinstate code is similarly easier than removing the #| |# pair.
∂19-Mar-86 1002 Gregor.pa@Xerox.COM Re: Ignoring a list.
Received: from XEROX.COM by SU-AI.ARPA with TCP; 19 Mar 86 10:02:12 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 19 MAR 86 09:49:26 PST
Date: 19 Mar 86 09:50 PST
From: Gregor.pa@Xerox.COM
Subject: Re: Ignoring a list.
In-reply-to: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>'s message of Wed,
19 Mar 86 10:13 EST
To: DCP@SCRC-QUABBIN.ARPA
cc: greek%bach.decnet@hudson.dec.com, common-lisp@SU-AI.ARPA
Message-ID: <860319-094926-2920@Xerox>
This seems like an environment issue to me, and not one that the
language needs to take a stand on. After all:
- A particular environment might have some really nice way of
implementing and supporting this feature. It could gray the form out,
or turn it blue or something. In that environment the "standard" way of
implementing it might not be useful or it might be difficult to provide
really nice environment support for it.
- There is no significant need for a "standard" way to do this because
the only time a user really needs to comment out random forms (in a
hurry) is when they are debugging. If you are debugging then you
already have to learn enough about the environment that knowing how to
comment out a form does not seem like such a burden.
- To the extent that we do need a "standard" way of doing this (which I
have argued above is a small extent). there is already a standard way of
doing it. Take the name of the lisp you are using and use #-, as in
#-FooLisp.
∂19-Mar-86 1159 preece%ccvaxa@gswd-vms Re: Ignoring a list.
Received: from GSWD-VMS.ARPA by SU-AI.ARPA with TCP; 19 Mar 86 11:57:16 PST
Received: from ccvaxa.GSD (ccvaxa.ARPA) by gswd-vms.ARPA (5.9/)
id AA07213; Wed, 19 Mar 86 13:17:15 CST
Message-Id: <8603191917.AA07213@gswd-vms.ARPA>
Date: Wed, 19 Mar 86 13:12:54 cst
From: preece%ccvaxa@gswd-vms (Scott E. Preece)
To: COMMON-LISP@su-ai.arpa
Subject: Re: Ignoring a list.
From: Gregor.pa@Xerox.COM
Subject: Re: Ignoring a list.
This seems like an environment issue to me, and not one that the
language needs to take a stand on. After all:
- A particular environment might have some really nice way of
implementing and supporting this feature. It could gray the form out,
or turn it blue or something. In that environment the "standard" way of
implementing it might not be useful or it might be difficult to provide
really nice environment support for it.
----------
A particular environment might have a really nice way of supporting
comments, say by displaying them in italics or boxes. Therefore the
standard shouldn't provide a standard way of indicating comments...
----------
- There is no significant need for a "standard" way to do this because
the only time a user really needs to comment out random forms (in a
hurry) is when they are debugging. If you are debugging then you
already have to learn enough about the environment that knowing how to
comment out a form does not seem like such a burden.
----------
I suppoose it's slightly tacky to ship code with debugging support in
it, but I'd really like to know that my commented-out forms will still
be commented out on the standard system I deliver them to. Also, there
is a limited set of #s reserved to the user -- I would prefer this form
came from the general "undefined" pot rather than the "undefined and
guaranteed never to be defined" pot.
----------
- To the extent that we do need a "standard" way of doing this (which I
have argued above is a small extent).there is already a standard way of
doing it. Take the name of the lisp you are using and use #-, as in
#-FooLisp.
----------
So somebody taking my code and trying (silly person) to port it to
another CL will suddenly have my commented-out code reappearing?
This isn't really a major issue, but the ability to comment out a
form by marking the beginning of it seems like a very useful ability
to have. Marking both ends is (a) a pain in the ass, even if it does
take only two keystrokes to get to the end of the form and (b) much
more prone to the "oops, i took out the front one but not the back one"
variety of error.
--
scott preece
gould/csd - urbana
ihnp4!uiucdcs!ccvaxa!preece
∂19-Mar-86 1434 Masinter.pa@Xerox.COM Re: Ignoring a list.
Received: from XEROX.COM by SU-AI.ARPA with TCP; 19 Mar 86 14:33:46 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 19 MAR 86 14:33:52 PST
Date: 19 Mar 86 14:32 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Ignoring a list.
To: COMMON-LISP@su-ai.ARPA
Message-ID: <860319-143352-3298@Xerox>
While we're having this silly discussion:
my standard way of commenting out code is
(if nil ..code..)
and then putting it back in is
(if t ..code..)
You have to mark both ends to comment it out, but then putting it back in is trivial.
You can comment the nil and t if you want.
∂19-Mar-86 2056 α@uw-beaver.arpa
Received: from UW-BEAVER.ARPA by SU-AI.ARPA with TCP; 19 Mar 86 20:56:10 PST
Received: by uw-beaver.arpa (4.42/4.2)
id AA16448; Wed, 19 Mar 86 21:03:33 PST
Date: Wed, 19 Mar 86 21:03:33 PST
From: α@uw-beaver.arpa
Return-Path: <α@uw-beaver.arpa>
Message-Id: <8603200503.AA16448@uw-beaver.arpa>
Apparently-To: COMMON-LISP@SU-AI.ARPA
∂20-Mar-86 1327 MATHIS@USC-ISIF.ARPA SPARC Endorses X3J13
Received: from USC-ISIF.ARPA by SU-AI.ARPA with TCP; 20 Mar 86 13:27:23 PST
Date: 20 Mar 1986 13:26-PST
Sender: MATHIS@USC-ISIF.ARPA
Subject: SPARC Endorses X3J13
From: MATHIS@USC-ISIF.ARPA
To: Common-Lisp@SU-AI.ARPA
Cc: Mathis@USC-ISIF.ARPA
Message-ID: <[USC-ISIF.ARPA]20-Mar-86 13:26:04.MATHIS>
NEWS: Today SPARC endorsed the proposal for the formation of a
new X3 technical committee (X3J13) for work on a standard for
Common Lisp. It now goes forward to a full X3 vote.
SPARC also endorsed the associated new work item (NWI) proposal
for an ISO standard for Common Lisp. This also goes to X3 for a
vote and then into the ISO structure.
For more information contact: Bob Mathis, 9712 Ceralene Drive,
Fairfax, VA 22032-1704, (703)-425-5923
∂20-Mar-86 1415 DD60@A.CS.CMU.EDU Standardization
Received: from A.CS.CMU.EDU by SU-AI.ARPA with TCP; 20 Mar 86 14:15:38 PST
Date: Thu, 20 Mar 86 17:02 EST
From: David.Dill@A.CS.CMU.EDU (C410DD60)
To: common-lisp@su-ai.arpa
Subject: Standardization
Message-Id: <20Mar86.170218.DD60@A.CS.CMU.EDU>
To what extent can Common Lisp be changed in the process of becoming a
standard?
∂20-Mar-86 1537 DCP@ALLEGHENY.SCRC.Symbolics.COM Standardization
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 20 Mar 86 15:37:41 PST
Received: from FIREBIRD.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 7203; Thu 20-Mar-86 18:37:42-EST
Date: Thu, 20 Mar 86 18:37 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: Standardization
To: C410DD60 <David.Dill@A.CS.CMU.EDU>, common-lisp@SU-AI.ARPA
In-Reply-To: <20Mar86.170218.DD60@A.CS.CMU.EDU>
Message-ID: <860320183705.3.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Thu, 20 Mar 86 17:02 EST
From: David.Dill@A.CS.CMU.EDU (C410DD60)
To what extent can Common Lisp be changed in the process of becoming a
standard?
Let's call the thing published by Digital Press CLtL'84. Let's also
assume that the typos and clarifications are also part of the language.
There have been some proposed extensions and some proposed changes to
CLtL'84. Some of these are acknowledged bugs in the language, e.g.,
GET-SETF-METHOD needs to take an environment. Others are not, e.g.,
should the TRUE and FALSE functions be put into the language?
I hope that the ANSI/ISO standardization is not a rubber stamping of
CLtL'84 but instead incorporates or addresses the ideas and proposals in
the years since then. The result may drop some things that are in
CLtL'84 and add other things. Yes, this means incompatible, and it
means that vendors have to say "We implement CLtL'84" or "We implement
ISO Lisp ye6.4.t9", but on the other hand, most vendors, and perhaps
this list, may agree that the ANSI/ISO version overrides CLtL'84.
∂20-Mar-86 2315 cfry%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU Re: Ignoring a list.
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 20 Mar 86 23:15:18 PST
Received: from MORRISON.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 21 Mar 86 01:54-EST
Date: Fri, 21 Mar 86 01:52 EST
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
Subject: Re: Ignoring a list.
To: preece%ccvaxa@GSWD-VMS.ARPA, COMMON-LISP@SU-AI.ARPA
In-Reply-To: <8603191917.AA07213@gswd-vms.ARPA>
Message-ID: <860321015236.4.CFRY@MIT-MORRISON.ARPA>
From: Gregor.pa@Xerox.COM
Subject: Re: Ignoring a list.
This seems like an environment issue to me, and not one that the
language needs to take a stand on. After all:
- A particular environment might have some really nice way of
implementing and supporting this feature. It could gray the form out,
or turn it blue or something. In that environment the "standard" way of
implementing it might not be useful or it might be difficult to provide
really nice environment support for it.
----------
A particular environment might have a really nice way of supporting
comments, say by displaying them in italics or boxes. Therefore the
standard shouldn't provide a standard way of indicating comments...
----------
Such a fancy environment could manage to hide a char sequence like #;
- There is no significant need for a "standard" way to do this because
the only time a user really needs to comment out random forms (in a
hurry) is when they are debugging.
I spend most of my time debugging.
If you are debugging then you
already have to learn enough about the environment that knowing how to
comment out a form does not seem like such a burden.
Yeah, but lets make it as easy as we can.
This isn't really a major issue, but the ability to comment out a
form by marking the beginning of it seems like a very useful ability
to have. Marking both ends is (a) a pain in the ass, even if it does
take only two keystrokes to get to the end of the form and (b) much
more prone to the "oops, i took out the front one but not the back one"
variety of error.
I agree. Here's the proposals for commenting out a form via prefix syntax that
I've seen so far:
#! currently reserved for users
#-T where T would be a feature of every implementation
#+IGNORE Where IGNORE could not be a feature in any lisp implementation
#; possible conflict with the syntax for comment to end of line
#+(or) clever but not immediately obvious
#-(and) clever but not immediately obvious
Most # letter combinations are presently undefined and not reserved for
the user. Unfortunately, #c is used for complex numbers.
Maybe the next best is #d {"Don't use" or "semantically Delete from program"}
There are about 10 other oddball chars that are not defined or reserved for
# reader macros. They are:
" $ % & > @ ↑ ← ` ~
Out of these, I guess I'd favor #% but I have no strong preference.
#; is easy to remember for those of us already use to the semicolon comment.
How much editor or whatever code is out there that would have to be
modified?
∂21-Mar-86 0840 MATHIS@USC-ISIF.ARPA Re: Standardization
Received: from USC-ISIF.ARPA by SU-AI.ARPA with TCP; 21 Mar 86 08:39:54 PST
Date: 21 Mar 1986 07:24-PST
Sender: MATHIS@USC-ISIF.ARPA
Subject: Re: Standardization
From: MATHIS@USC-ISIF.ARPA
To: David.Dill@A.CS.CMU.EDU
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[USC-ISIF.ARPA]21-Mar-86 07:24:03.MATHIS>
In-Reply-To: <20Mar86.170218.DD60@A.CS.CMU.EDU>
One of the difficult issues in any standrads effort is what to
change and what to keep the same (or at least compatible).
What's one person's bug is another's feature. I think most
people want the standard to be very nearly what people think of
today when they say "Common Lisp," but the formal agreement on
that mutual understanding can be very difficult and may result in
some unexpected changes. -- Bob Mathis
∂21-Mar-86 0952 gls@THINK-AQUINAS.ARPA Standardization
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 21 Mar 86 09:51:57 PST
Received: from yon by GODOT.THINK.COM via CHAOS; Fri, 21 Mar 86 12:52:37 est
Date: Fri, 21 Mar 86 12:54 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Standardization
To: David.Dill@A.CS.CMU.EDU, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <20Mar86.170218.DD60@A.CS.CMU.EDU>
Message-Id: <860321125427.3.GLS@THINK-YON.ARPA>
Date: Thu, 20 Mar 86 17:02 EST
From: David.Dill@A.CS.CMU.EDU (C410DD60)
To what extent can Common Lisp be changed in the process of becoming a
standard?
To what extent CAN it be changed? Arbitrarily (unfortunately), but if
you change it too much then everyone will abandon it. Fortunately there
are balancing pressures. To what extent SHOULD it be changed? My
opinion is that what is there is mostly sound (I happen to be proud of
what the committee produced in the initial design), but that ambiguities
must be clarified, which will inevitably require some changes in some
implementations, and certain extensions are needed (such as error
handling).
∂21-Mar-86 1023 FAHLMAN@C.CS.CMU.EDU Standardization
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 21 Mar 86 10:23:23 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 21 Mar 86 13:24:43-EST
Date: Fri, 21 Mar 1986 13:24 EST
Message-ID: <FAHLMAN.12192518522.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Standardization
In-reply-to: Msg of 21 Mar 1986 12:54-EST from Guy Steele <gls at THINK-AQUINAS.ARPA>
I agree with most of what Guy Steele and Bob Mathis have said on the
subject of how much we want to change the language in the course of
producing this first standard. I would add only two things:
First, I think that it would not be out of order to consider
incompatible changes, even where the current language is unambiguous and
implementable, if we really feel that the change is worth it. But in
all such considerations, we must bear in mind the costs as well as any
possible benefits. There are now a lot of Common Lisp implementations
around, a growing body of Common Lisp software, tutorial material on the
language, and some users who have invested time in learning this
language. By the time the standard is ready, there will be a lot more.
The more of this investment that a proposed change would effect, the
more benfit we would have to see in order for the change to be adopted.
We certainly are not looking at a situation where we have license to
start from scratch or to make a lot of gratuitous changes based on minor
aesthetic considerations.
The other thing to say is that before beginning this in earnest, we may
want to plan on the existence of future versions that could make more
radical changes (given a lot more lead time and a stable Common Lisp
where people can get work done while waiting for the changes). I think
that for many good, pragmatic reasons we need to standardize something
like the current Common Lisp, but this is certainly not the last word in
programming languages, and if we think carefully about when the next
wave might break, we might have a better idea of what we can afford to
change, or not to change, in this one.
-- Scott
∂25-Mar-86 0306 liz@brillig.umd.edu Re: Standardization
Received: from BRILLIG.UMD.EDU by SU-AI.ARPA with TCP; 25 Mar 86 03:02:01 PST
Received: by brillig.umd.edu (5.9/4.7)
id AA03479; Mon, 24 Mar 86 17:24:33 EST
Message-Id: <8603242224.AA03479@brillig.umd.edu>
To: common-lisp@su-ai.ARPA
Subject: Re: Standardization
In-Reply-To: Your message of Fri, 21 Mar 1986 13:24 EST.
<FAHLMAN.12192518522.BABYL@C.CS.CMU.EDU>
Date: Mon, 24 Mar 86 17:24:32 -0500
From: Liz Allen <liz@brillig.umd.edu>
Just a note from experience and a question for thought...
I once tried to port some code that ran fine under DEC Common Lisp
to LMI's Common Lisp and had *lots* of trouble -- in fact, I finally
had to give up. Now the system I was porting (Drew McDermott's
deductive retrieval system, DUCK) did some interesting things and
was probably pushing some things beyond their normal limits. Still,
there were some surprises that seemed to me like real incompatibilities.
(I could probably dig them up if someone wants to see them.) Maybe
things have improved since then, but I can't help wondering how
standard everything really is. Has anyone else tried porting common
lisp code from one implementation to another? If so, how did it
go? If not, maybe it ought to be tried...
-Liz
∂25-Mar-86 1059 @MIT-ZERMATT.ARPA:Soley@MIT-MC.ARPA Re: Standardization
Received: from MIT-ZERMATT.ARPA by SU-AI.ARPA with TCP; 25 Mar 86 10:58:11 PST
Received: from MIT-CHERRY.ARPA by MIT-ZERMATT.ARPA via CHAOS with CHAOS-MAIL id 29025; Tue 25-Mar-86 13:59:14-EST
Date: Tue, 25 Mar 86 13:58 EST
From: Soley@MIT-MC.ARPA
Subject: Re: Standardization
To: liz%brillig.umd.edu@MIT-MC.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <8603242224.AA03479@brillig.umd.edu>
Message-ID: <860325135846.3.SOLEY@MIT-CHERRY.ARPA>
Message-Id: <8603242224.AA03479@brillig.umd.edu>
To: common-lisp@su-ai.ARPA
Subject: Re: Standardization
In-Reply-To: Your message of Fri, 21 Mar 1986 13:24 EST.
<FAHLMAN.12192518522.BABYL@C.CS.CMU.EDU>
Date: Mon, 24 Mar 86 17:24:32 -0500
From: Liz Allen <liz@brillig.umd.edu>
I once tried to port some code that ran fine under DEC Common Lisp
to LMI's Common Lisp and had *lots* of trouble -- in fact, I finally
had to give up. Now the system I was porting (Drew McDermott's
deductive retrieval system, DUCK) did some interesting things and
was probably pushing some things beyond their normal limits.
I have ported DUCK several times (actually, several times too many . . .),
and it could hardly be considered a candidate for most portable program
of the year.
Has anyone else tried porting common lisp code from one
implementation to another? If so, how did it go?
I have also ported several other medium-sized CL programs, between
Symbolics, TI, Gold Hill, NIL, and others, and have been fairly happy
with how it went.
∂25-Mar-86 1059 JAR@MC.LCS.MIT.EDU Standardization
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 25 Mar 86 10:59:10 PST
Date: Tue, 25 Mar 86 14:01:09 EST
From: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
Subject: Standardization
To: liz@BRILLIG.UMD.EDU
cc: common-lisp@SU-AI.ARPA
Message-ID: <[MC.LCS.MIT.EDU].861386.860325.JAR>
Date: Mon, 24 Mar 86 17:24:32 -0500 From:
Liz Allen <liz at brillig.umd.edu>
Has anyone else tried porting common lisp code from one
implementation to another? If so, how did it go?
My scheme implementation has been run in at least four common lisp
implementations now. Nearly every problem I had was due to a bug in the
implementation. A small number of other problems (like LISP package
pollution) were due to language deficiencies which I believe can and
will be fixed fairly painlessly by the standardization process.
∂25-Mar-86 1141 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Re: Standardization
Received: from CS.UCL.AC.UK by SU-AI.ARPA with TCP; 25 Mar 86 11:37:05 PST
Received: from aiva.edinburgh.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP
id a002819; 25 Mar 86 19:04 BST
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@cs.ucl.ac.uk>
Date: Tue, 25 Mar 86 17:19:29 GMT
Message-Id: <14603.8603251719@aiva.ed.ac.uk>
To: common-lisp@su-ai.arpa, liz@brillig.umd.edu
Subject: Re: Standardization
Cc: eulisp%inria.uucp@cs.ucl.ac.uk
From: Liz Allen <liz@edu.umd.brillig>
I once tried to port some code that ran fine under DEC Common Lisp
to LMI's Common Lisp and had *lots* of trouble -- in fact, I finally
had to give up. ... Has anyone else tried porting common lisp code
from one implementation to another?
(I imagine that the implementors of things like CommonLoops could also
comment on this subject.)
I have ported several programs of varying sizes (up to 150 pages or so)
from Spice Lisp to Kyoto Common Lisp (KCL) and then to Sun (Lucid) Common
Lisp. Some of this code was originally written in Spice Lisp, but other
parts came from Franz Lisp or even T. I have also written some new code
that was to run in both KCL and Sun Lisp; most of this has not been tried
in Spice. Finally, I have ported some of things to Poplog Common Lisp.
(The KCL and Poplog cases are particularly enlightening in that they were
developed by people outside the central Common Lisp community and hence
had to depend more on the published description of the language.) None of
my code depended on things outside the Silver Book, and except where blocked
by bugs I was always able to get something that worked everywhere in the end.
Nonetheless, it was a rare program that could be ported as-is.
In general, incompatibilities could be attributed to any of several reasons,
here listed roughly in order of decreasing frequency:
1. Incorrect interpretations of the language specification.
These are cases that *I* think are wrong but where (a) the implementa-
tion seems to be meant to work this way and (b) it is possible to see
how someone might have understood the CLtL in this way. Many of these
involve packages.
2. Bugs in the implementations.
The cases I think are wrong that don't meet criteria (a) and (b). This
includes faulty handling of incorrect programs. (Incidentally, this
category is becoming more common and may be number one any day now.
Perhaps I initially used parts of the language that were more thoroughly
debugged.)
3. Allowed differences.
Implementations of Common Lisp are allowed to differ in certain ways
apart from internal implementation details. Examples would be potential
numbers (p. 341) and symbols like "::" (p. 176).
Some implementations enforce a stricter interpretation of the language
than others in the sense that programs that work in the stricter system
will work in less strict ones but not the other way around. In this case,
it helps to start in the stricter system because then you will be
warned about things like potential numbers that you might otherwise
have overlooked in CLtL.
Extensions to Common Lisp can also be a problem. For example, if a system
defines a new external symbol in the Lisp package, and I have a program
that also defines that symbol, I will have to do something to resolve the
conflict. (Would it be reasonable to require that extensions be defined
in a different package?)
4. Implementation or environment differences.
Some programs will have difficulties in some systems because of the
machine or the operating system involved or because things like storage
management are done differently. Sometimes it is helpful (or necessary)
to rewrite parts of the program.
This differs from category (3) in that there isn't much that the language
definition can do. We could say what must be done with potential numbers,
but we could hardly require that all systems must have the same
performance. Cases like the treatment of tail-recursion may fall
somewhere in between.
5. Ambiguities, inconsistencies, or mistakes in the specification.
This is similar to case (1) except that the specification is (more)
clearly at fault. Note that many of the inconsistencies are due to
uneven revision, things missed when parts of the language were changed;
others have origins that are less obvious.
6. Uneven development.
Some implementations are more up-to-date than others in that they may
have responded to changes or clarifications that were discussed on this
mailing list.
Of these categories, (1), (3), and (5) have implications for standardization,
(1) and (5) because a standard needs a clear, precise, and consistent
specification, and (3) because it shows that some incompatibilities are
inherent in Common Lisp; after all, Common Lisp is meant to be a common
subset.
It is also important to note that all of this can be improved. There do
not seem to be any "fatal inconsistencies" that would bring down a large
part of the language. To me, this means that a standard can be based on
Common Lisp, but also that improvements in the specification are needed.
(A final note: Clearly the number of cases in each category, and hence
their order, reflects the selection of dialects involved (how could it be
otherwise?), but many of the obvious conclusions about these dialects do
not hold. I say this, without saying what those conclusions would be, to
avoid giving a false, negative impression of any of these systems. I don't
feel this is the right place to make such comparisons.)
-- Jeff
∂25-Mar-86 1206 gls@GODOT.THINK.COM Suggestions for language changes
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 25 Mar 86 11:59:32 PST
Received: by GODOT.THINK.COM; Tue, 25 Mar 86 15:00:08 est
Date: Tue, 25 Mar 86 15:00:08 est
From: gls@GODOT.THINK.COM (Guy Steele)
Message-Id: <8603252000.AA08699@GODOT.THINK.COM>
To: common-lisp@sail
Subject: Suggestions for language changes
The following suggestions were made to me orally at the
December meeting. I just ran across my notes again, and
am sending these out now in case I didn't before.
I apologize for the fact that I failed to note who made
which suggestions, and memory fails me.
[1] Clarify what division by zero does.
[2] DENOMINATOR should be allowed to return 0 for non-standard
objects.
[3] TAGBODY should allow constants (specifically strings)
in the body, not as tags but simply to be effectively ignored.
[4] Clarify whether DEFSTRUCT or DEFTYPE can redefine a
built-in type.
[5] There should be a way to force a constituent to be purely
alphabetic in the lexer. Right now there is no way to make
colon be alphabetic and not a package marker, for example.
--Guy
∂25-Mar-86 1718 pyramid!pyrps5.bein@sri-unix comments...
Received: from SRI-UNIX.ARPA by SU-AI.ARPA with TCP; 25 Mar 86 17:11:02 PST
Received: by sri-unix.ARPA (4.12/4.16)
id AA26536; Tue, 25 Mar 86 15:09:19 pst
Received: from pyrps5 (pyrps5.ARPA) by pyramid (4.12/3.14)
id AA11288; Tue, 25 Mar 86 01:55:57 pst
Received: by pyrps5 (4.12/3.14)
id AA00513; Tue, 25 Mar 86 01:55:31 pst
Date: 25 Mar 1986 01:36-PST
From: David Bein <pyramid!pyrps5.bein@sri-unix>
Subject: comments...
To: common-lisp@SU-AI.ARPA
Message-Id: <512127419/bein@pyrps5>
Just to get my 2-cents worth in ...
Why not have the keyword :ignore be part of the STANDARD
features list? Then someone would not have the problem of knowing
whether it is or is not in the features list. So when you want to
eat an s-expression just do:
#-:ignore (mumble-frats ...)
On the other hand, I tend to agree with the purists that this
kind of mucking with the standard is to be avoided. So maybe it
would be appropriate if our mailers were taught to ignore letters
about things like this. Another idea is that we start attaching
a GC: <n> field to the letters we send out which can be
used by mail-reading programs to decide whether to "ignore"
this or that piece of mail.
--David
∂25-Mar-86 1948 GJC@MC.LCS.MIT.EDU the Duck port you gave up on.
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 25 Mar 86 19:48:20 PST
Date: Tue, 25 Mar 86 22:50:24 EST
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Subject: the Duck port you gave up on.
To: liz@BRILLIG.UMD.EDU
cc: common-lisp@SU-AI.ARPA
Message-ID: <[MC.LCS.MIT.EDU].861813.860325.GJC>
I can see why you gave up. The program referenced such jewels as
the internal macros used by the backquote-macros, COMPILER:QC-FILE-IN-PROGRESS,
not to mention various undocumented features of the DEC, Symbolics, and LMI
implementation. In fact this is a classic case of pre-common-lisp lossage.
Porting the previous "zetalisp" version from Symbolics rel 6 took me
only 3 hours. So the "commonlispification" of DUCK in this case was
somewhat misguided. What you had was a program that was painfully
hacked to work in DEC's VAX implementation.
{Insert a short history of NISP, and the port to T...}
Better luck next time.
∂26-Mar-86 1501 DCP@ALLEGHENY.SCRC.Symbolics.COM inline declaration for FLET and LABELS
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 26 Mar 86 15:01:28 PST
Received: from FIREBIRD.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 8824; Tue 25-Mar-86 11:02:32-EST
Date: Tue, 25 Mar 86 11:04 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: inline declaration for FLET and LABELS
To: common-lisp@SU-AI.ARPA
Message-ID: <860325110403.9.DCP@FIREBIRD.SCRC.Symbolics.COM>
A few of us just realized that
(defun foo ()
(labels ((bar ...)
(baz ...))
(declare (inline bar baz))
...))
is realitively easy to implement compare to
(defun foo ()
(flet ((bar ...)
(baz ...))
(declare (inline bar baz))
...))
The problem is the scoping rules. Consider
(defun foo ()
(flet ((car (x) (cdr x))
(cdr (x) (car x)))
(declare (inline car cdr))
...))
While this is quite legal, it may be VERY hard to implement. Therefore,
when we consider allowing inline declarations for local functions, we
should keep this in mind in the documentation.
∂27-Mar-86 0855 PGS@AI.AI.MIT.EDU inline declaration for FLET and LABELS
Received: from AI.AI.MIT.EDU by SU-AI.ARPA with TCP; 27 Mar 86 08:55:20 PST
Date: Thu, 27 Mar 86 11:56:25 EST
From: "Patrick G. Sobalvarro" <PGS@AI.AI.MIT.EDU>
Subject: inline declaration for FLET and LABELS
To: DCP@SCRC-QUABBIN.ARPA
cc: common-lisp@SU-AI.ARPA
In-reply-to: Msg of Tue 25 Mar 86 11:04 EST from David C. Plummer <DCP at SCRC-QUABBIN.ARPA>
Message-ID: <[AI.AI.MIT.EDU].21839.860327.PGS>
Date: Tue, 25 Mar 86 11:04 EST
From: David C. Plummer <DCP at SCRC-QUABBIN.ARPA>
A few of us just realized that
(defun foo ()
(labels ((bar ...)
(baz ...))
(declare (inline bar baz))
...))
is realitively easy to implement compare to
(defun foo ()
(flet ((bar ...)
(baz ...))
(declare (inline bar baz))
...))
The problem is the scoping rules. Consider
(defun foo ()
(flet ((car (x) (cdr x))
(cdr (x) (car x)))
(declare (inline car cdr))
...))
While this is quite legal, it may be VERY hard to implement. Therefore,
when we consider allowing inline declarations for local functions, we
should keep this in mind in the documentation.
I'm not sure I understand this -- do you have your flet and your labels
backwards here? In that case, I think that most compilers that couldn't do
block compilation would just ignore inline declarations when they caused
circularities. Consider that the situation you're describing isn't too
different from compiling globally defined mutually recursive functions that
are declared inline.
∂27-Mar-86 1021 DCP@ALLEGHENY.SCRC.Symbolics.COM inline declaration for FLET and LABELS
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 27 Mar 86 10:21:38 PST
Received: from FIREBIRD.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 9517; Thu 27-Mar-86 13:12:36-EST
Date: Thu, 27 Mar 86 13:20 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: inline declaration for FLET and LABELS
To: Patrick G. Sobalvarro <PGS@AI.AI.MIT.EDU>, DCP@SCRC-QUABBIN.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <[AI.AI.MIT.EDU].21839.860327.PGS>
Message-ID: <860327132013.1.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Thu, 27 Mar 86 11:56:25 EST
From: "Patrick G. Sobalvarro" <PGS@AI.AI.MIT.EDU>
Date: Tue, 25 Mar 86 11:04 EST
From: David C. Plummer <DCP at SCRC-QUABBIN.ARPA>
A few of us just realized that
(defun foo ()
(labels ((bar ...)
(baz ...))
(declare (inline bar baz))
...))
is realitively easy to implement compare to
(defun foo ()
(flet ((bar ...)
(baz ...))
(declare (inline bar baz))
...))
The problem is the scoping rules. Consider
(defun foo ()
(flet ((car (x) (cdr x))
(cdr (x) (car x)))
(declare (inline car cdr))
...))
While this is quite legal, it may be VERY hard to implement. Therefore,
when we consider allowing inline declarations for local functions, we
should keep this in mind in the documentation.
I'm not sure I understand this -- do you have your flet and your labels
backwards here? In that case, I think that most compilers that couldn't do
block compilation would just ignore inline declarations when they caused
circularities. Consider that the situation you're describing isn't too
different from compiling globally defined mutually recursive functions that
are declared inline.
The problem is that when you expand an FLET'ed or LABELS'ed function,
you have to 'fool' somebody by backing up the lexical environment
correctly. Consider this contoration:
(compiler-let ((*foo* 'foo))
(macrolet ((foo () `'(outer ,*foo*)))
(flet ((foo1 () (foo)))
(flet ((foo2 () (foo1)))
(declare (inline foo2))
(compiler-let ((*foo* 'bar))
(macrolet ((foo () `'(inner ,*foo*)))
(flet ((foo1 () (foo)))
(foo2))))))))
This is supposed to return (OUTER FOO). If the call to FOO2 were
expanded into FOO1 but the environment were not unrolled, it would
instead return (INNER BAR). I'm not saying it is impossible; I'm saying
it is probably damn hard to implement.
∂27-Mar-86 1059 BROOKS%OZ.AI.MIT.EDU@AI.AI.MIT.EDU Re: inline declaration for FLET and LABELS
Received: from AI.AI.MIT.EDU by SU-AI.ARPA with TCP; 27 Mar 86 10:59:22 PST
Date: Thu 27 Mar 86 13:40:03-EST
From: "Rodney A. Brooks" <BROOKS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Subject: Re: inline declaration for FLET and LABELS
To: DCP@SCRC-QUABBIN.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <860327132013.1.DCP@FIREBIRD.SCRC.Symbolics.COM>
Message-ID: <12194094203.57.BROOKS@OZ.AI.MIT.EDU>
The problem is that when you expand an FLET'ed or LABELS'ed function,
you have to 'fool' somebody by backing up the lexical environment
correctly. Consider this contoration:
(compiler-let ((*foo* 'foo))
(macrolet ((foo () `'(outer ,*foo*)))
(flet ((foo1 () (foo)))
(flet ((foo2 () (foo1)))
(declare (inline foo2))
(compiler-let ((*foo* 'bar))
(macrolet ((foo () `'(inner ,*foo*)))
(flet ((foo1 () (foo)))
(foo2))))))))
This is supposed to return (OUTER FOO). If the call to FOO2 were
expanded into FOO1 but the environment were not unrolled, it would
instead return (INNER BAR). I'm not saying it is impossible; I'm saying
it is probably damn hard to implement.
Correct. It is hard but not impossible. For Lucid's compiler this was
one of three places (the other two were to do with shared environments
for closures) I had to introduce variations on source level special
forms during alphatization that are not available at user level.
Basically I alphatize the body of the flet defined function in the
environment where it is defined, and then for inline susbstitution
protect it from re-alphatization with an extension to locally.
Alphatization uniquifies everything so eventually all the references
are right.
(I'm not sure this is yet in any released version but will be soon.)
-------
∂27-Mar-86 1133 JAR@MC.LCS.MIT.EDU inline declaration for FLET and LABELS
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 27 Mar 86 11:24:17 PST
Date: Thu, 27 Mar 86 14:26:20 EST
From: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
Subject: inline declaration for FLET and LABELS
To: DCP@SCRC-QUABBIN.ARPA
cc: common-lisp@SU-AI.ARPA
In-reply-to: Msg of Thu 27 Mar 86 13:20 EST from David C. Plummer <DCP at SCRC-QUABBIN.ARPA>
Message-ID: <[MC.LCS.MIT.EDU].863705.860327.JAR>
I've implemented it a couple times and never had any trouble, but then
I've never tried to write a compiler which tried to implement
optimizations via macro expansion. It's best in lexical languages
either to uniquely rename user variables like RABBIT does, or to make
"virtual closures" to make sure that lambda-expressions know what
lexical environment they came from (I've never tried that although I
think it would work). The LETREC case seems harder to me since you have
to deal with mutual recursion.
∂28-Mar-86 0823 NGALL@G.BBN.COM Predicates for all type specifier symbols
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 28 Mar 86 08:20:27 PST
Date: 28 Mar 1986 11:20-EST
Sender: NGALL@G.BBN.COM
Subject: Predicates for all type specifier symbols
From: NGALL@G.BBN.COM
To: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]28-Mar-86 11:20:13.NGALL>
Why aren't there predicate functions for ALL the type specifier
symbols in Table 4-1 (pg 43)? The following type sepecs. lack an
associated predicate (I think):
bignum
bit
double-float
fixnum
long-float
nil
ratio
sequence
short-float
simple-array
single-float
t
(and the proposed)
signed-byte
unsigned-byte
Its a pain having to keep track of which ones have predicates and
which ones don't.
Also, If we had TP and NILP we would have the TRUE and FALSE functions
that KMP was asking for!
While I'm on this Table, let me suggest a few more type specs:
closure
form
lambda-expression
place
printed
readable-object {covers only those objects that can posssibly have a readable
representation.}
type-specifier
boolean {equiv. to (member t nil)}
function-name {covers only those objects that may be an arg of the
FUNCTION special form; equiv. to
(or symbol lambda-expression)}
function-definition {covers only those things that symbol-function
returns}
-- Nick
∂28-Mar-86 0901 DCP@ALLEGHENY.SCRC.Symbolics.COM Re: inline declaration for FLET and LABELS
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 28 Mar 86 09:00:14 PST
Received: from FIREBIRD.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 9801; Fri 28-Mar-86 11:51:25-EST
Date: Fri, 28 Mar 86 11:58 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: Re: inline declaration for FLET and LABELS
To: Rodney A. Brooks <BROOKS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>,
DCP@SCRC-QUABBIN.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <12194094203.57.BROOKS@OZ.AI.MIT.EDU>
Message-ID: <860328115855.6.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Thu 27 Mar 86 13:40:03-EST
From: "Rodney A. Brooks" <BROOKS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
The problem is that when you expand an FLET'ed or LABELS'ed function,
you have to 'fool' somebody by backing up the lexical environment
correctly. Consider this contoration:
(compiler-let ((*foo* 'foo))
(macrolet ((foo () `'(outer ,*foo*)))
(flet ((foo1 () (foo)))
(flet ((foo2 () (foo1)))
(declare (inline foo2))
(compiler-let ((*foo* 'bar))
(macrolet ((foo () `'(inner ,*foo*)))
(flet ((foo1 () (foo)))
(foo2))))))))
This is supposed to return (OUTER FOO). If the call to FOO2 were
expanded into FOO1 but the environment were not unrolled, it would
instead return (INNER BAR). I'm not saying it is impossible; I'm saying
it is probably damn hard to implement.
Correct. It is hard but not impossible. For Lucid's compiler this was
one of three places (the other two were to do with shared environments
for closures) I had to introduce variations on source level special
forms during alphatization that are not available at user level.
Basically I alphatize the body of the flet defined function in the
environment where it is defined, and then for inline susbstitution
protect it from re-alphatization with an extension to locally.
Alphatization uniquifies everything so eventually all the references
are right.
(I'm not sure this is yet in any released version but will be soon.)
Indeed, I can see how that can work. [Putting on my programming
environment hat...] Implemenations should be careful that what they put
in source locators and debugging information should correspond to what
the user input, not what the compiler uniquified things to. For
example, in the Symbolics implementation, the function spec of FLET and
LABELS functions is
(:INTERNAL <parent-fspec> <unique-index> <user-name-of-local-function>)
For example, the FOO1, FOO2 and (the second) FOO1 in the above form, if
they were in a function called BAR, would be
(:INTERNAL BAR 0 FOO1)
(:INTERNAL BAR 1 FOO2)
(:INTERNAL BAR 2 FOO1)
∂28-Mar-86 0943 greek%bach.decnet@hudson.dec.com Predicates for types.
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 28 Mar 86 09:43:42 PST
Date: 28 Mar 86 12:32:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: Predicates for types.
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Interesting you should mention those. I would suggest that we get
rid of the ones we have and just use TYPEP. Of course, we can't
get rid of them for sake of compatability.
- Paul
------
∂28-Mar-86 1202 Gregor.pa@Xerox.COM Re: Standardization
Received: from XEROX.COM by SU-AI.ARPA with TCP; 28 Mar 86 12:02:28 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 28 MAR 86 11:57:27 PST
Date: 28 Mar 86 11:57 PST
From: Gregor.pa@Xerox.COM
Subject: Re: Standardization
In-reply-to: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@cs.ucl.ac.uk>'s
message of Tue, 25 Mar 86 17:19:29 GMT
To: jeff%aiva.edinburgh.ac.uk@cs.ucl.ac.uk
cc: common-lisp@su-ai.arpa, liz@brillig.umd.edu,
eulisp%inria.uucp@cs.ucl.ac.uk
Message-ID: <860328-115727-3499@Xerox>
I do intend to send out a message summarizing the problems I have had
making Portable CommonLoops.
I Have been going through the sources looking for places where I have
comments saying things like "this would be easier if Common Lisp
had...". I will try to finish this in the next couple of days and send
it out.
∂28-Mar-86 1208 RPG
∂28-Mar-86 1047 somewhere!yuasa@kurims.kurims.kyoto-u.junet
Received: from SU-SHASTA.ARPA by SU-AI.ARPA with TCP; 28 Mar 86 10:46:59 PST
Received: by su-shasta.arpa with TCP; Fri, 28 Mar 86 10:46:44 pst
Received: by ntt.junet (4.12/4.7JC-7) CHAOS with CHAOS-MAIL
id AA20839; Fri, 28 Mar 86 16:34:32 jst
From: yuasa@kurims.kurims.kyoto-u.junet
Received: by ntt.junet (4.12/4.7JC-7) CHAOS with CHAOS-MAIL
id AA20727; Fri, 28 Mar 86 16:31:44 jst
Received: by kurims.kyoto-u.junet (2.0/4.7)
id AA01026; Fri, 28 Mar 86 15:30:12 pst
Date: Fri, 28 Mar 86 15:30:12 pst
Message-Id: <8603282330.AA01026@kurims.kyoto-u.junet>
To: RPG@SU-AI.ARPA
Dear Dr.Gabriel,
We would like to join the discussions on Lisp
standardization for ANSI and ISO. Please add our names
to the Common Lisp mailing list. Our network addresses
are:
nttlab!kurims!yuasa@SU-SHASTA.ARPA
for Taiichi Yuasa
and
nttlab!kurims!hagiya@SU-SHASTA.ARPA
for Masami Hagiya
Thanks in advance.
Taiichi Yuasa and Masami Hagiya
Research Institute for Mathematial Sciences
Kyoto University, Kyoto 606, Japan
tel. 075-751-2111 ext.7238
∂28-Mar-86 1306 DICK%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU LetS -- a new loop notation
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 28 Mar 86 13:06:29 PST
Date: Fri, 28 Mar 1986 15:55 EST
Message-ID: <DICK.12194380978.BABYL@MIT-OZ>
Sender: DICK%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
From: Dick@MC.LCS.MIT.EDU
To: cl-iteration@SU-AI.ARPA, common-lisp@SU-AI.ARPA
Subject: LetS -- a new loop notation
In-reply-to: Msg of 1 Mar 1986 00:01-EST from Masinter.pa at Xerox.COM
This message advertises a Common Lisp macro package called LetS (rhymes with
process) which it is hoped will become a standard iteration facility in Common
Lisp. LetS makes it possible to write a wide class of algorithms which are
typically written as loops in a functional style which is similar to
expressions written with the Common Lisp sequence functions. LetS supports a
number of features which make LetS expressions more expressive than sequence
expressions. However, the key feature of LetS is that every LetS expression is
automatically transformed into an efficient iterative loop. As a result,
unlike sequence expressions, LetS expressions are just as efficient as the
traditional loop expressions they replace.
An experimental version of LetS currently exists on the MIT-AI machine in the
file "DICK;LETS BIN". Although LetS is written in Common Lisp, it has not yet
been tested on anything other than a Symbolics Lisp Machine. For various
detailed reasons it is unlikely to run on any other machine. Everyone who
wants to is invited to borrow this file and try LetS out. I am very
interested to hear any and all comments on LetS.
Extensive documentation of LetS is in the file "DICK;LETSD >" also on the
MIT-AI machine. Even people who do not have a Lisp Machine or are not able
to access the code are invited to read this documentation and make comments on
it. I am interested in getting as wide a feedback as possible. If you cannot
access the documentation file directly, send me your US mail address and I will
mail you a copy. The documentation is much too long to reliably send via
computer mail.
After an initial testing and feedback period, a final version of LetS which
runs under all Common Lisps will be created along with formal documentation.
This should happen within a couple of months.
A very brief summary of lets is included at the end of this message.
Dick Waters
!
The advantages (with respect to conciseness, readability, verifiability and
maintainability) of programs written in a functional style are well known. A
simple example of the clarity of the functional style is provided by the
Common Lisp program below. This function computes the sum of the positive
elements of a vector.
(defun sum-pos-vect (v)
(reduce #'+ (remove-if-not #'plusp v)))
A key feature of sum-pos-vect is that it makes use of an intermediate
aggregate data structure (a sequence) to represent the selected set of vector
elements. The use of sequences as intermediate quantities in computations
makes it possible to use functional composition to express a wide variety of
computations which are usually represented as loops. Unfortunately, as
typically implemented, sequence expressions are extremely inefficient.
The problem is that straightforward evaluation of a sequence expression
requires the actual creation of the intermediate sequence objects. Since
alternate algorithms using loops can often compute the same result without
creating any intermediate sequences, the overhead engendered by using sequence
expressions is quite reasonably regarded as unacceptable in many situations.
A solution to the problem of the inefficiency of sequence expressions is to
transform them into iterative loops which do not actually create any
intermediate sequences before executing them. For example, sum-pos-vect might
be transformed as shown below.
(defun sum-pos-vect-transformed (v)
(prog (index last sum element)
(setq index 0)
(setq last (length v))
(setq sum 0)
L (if (not (< index last)) (return sum))
(setq element (aref v index))
(if (plusp element) (setq sum (+ element sum)))
(setq index (1+ index))
(go L)))
Several researchers have investigated the automatic transformation of
sequence expressions into loops. For example, APL compilers transform many
kinds of sequence expressions into loops.
Unfortunately, there is a fundamental problem with the transformation of
sequence expressions into loops. Although many sequence expressions can be
transformed, many cannot. For example, Common Lisp provides a sequence
function (reverse) which reverses the elements in a sequence. Suppose that a
sequence expression enumerates a sequence, reverses it, and then reduces it to
some value. This sequence expression cannot be computed without using
intermediate storage for the enumerated sequence because the first element of
the reversed sequence is taken from the last element of the enumerated
sequence. There is no way to transform the sequence expression into an
efficient loop without eliminating the reverse operation.
A solution to the problems caused by the presence of non-transformable
sequence operations is to restrict the kinds of sequence operations which
are allowed so that every sequence expression is guaranteed to be
transformable. For example, one could start by outlawing the operation
reverse.
!
LETS
LetS supports a wide class of sequence expressions that are all guaranteed
to be transformable into efficient loops. In order to avoid confusion with
the standard Common Lisp data type sequence, the data type supported by LetS
is called a series.
Using LetS the program sum-pos-vect would be rendered as shown below. The
function Evector converts the vector v into a series which contains the same
elements in the same order. The function Tplusp is analogous to
(remove-if-not #'plusp ...) except that it operates on a series. The function
Rsum corresponds to (reduce #'+ ... :initial-value 0) except that it takes in
a series as its argument.
(defun sum-pos-vect-lets (v)
(Rsum (Tplusp (Evector v))))
LetS automatically transforms the body of this program as shown below. The
readability of the transformed code is reduced by the fact that it contains a
large number of gensymed variables. However, the code is quite efficient.
The only significant problem is that too many variables are used. (For
example, the variable #:vector5 is unnecessary.) However, this problem need
not lead to inefficiency during execution as long as a compiler which is
capable of simple optimizations is available.
(defun sum-pos-vect-lets-transformed (v)
(let (#:index12 #:last4 #:sum21 #:element11 #:vector5)
(tagbody (setq #:vector5 v)
(setq #:index12 0)
(setq #:last4 (length #:vector5))
(setq #:sum21 0)
#:p0 (if (not (< #:index12 #:last4)) (go #:e9))
(setq #:index12 (1+ #:index12))
(setq #:element11 (aref #:vector5 #:index12))
(if (not (plusp #:element11)) (go #:p0))
(setq #:sum21 (+ #:element11 #:sum21))
(go #:p0)
#:e9)
#:sum21))
RESTRICTIONS ENFORCED BY LETS
The key aspect of LetS is that it enforces a palatable (and not overly
strict) set of easily understandable restrictions which guarantee that every
series expression can be transformed into a highly efficient loop. This
allows programmers to write series expressions which are much easier to work
with than the loops they might otherwise write, without suffering a decrease
in efficiency.
There are two central restrictions which are enforced by LetS. First, every
series must be statically identifiable so that transformation can occur at
compile time rather than at run time. Second every series function is
required to be "in-order". A series function is said to be in-order if it
reads each input series in order, one element at a time, starting from the
first one, and if it creates the output series (if any) in order, one element
at a time, starting from the first one. In addition, the function must do
this without using internal storage for more than one element at a time for
each of the input and output series. For example, the series functions
Evector, Tplusp, and Rsum are all in-order. In contrast, the function reverse
is not in-order. (Reverse either has to read the input in reverse order, or
save up the elements until the last one is read in.)
!
OTHER FEATURES OF LETS
Although efficiency is the main goal of LetS, LetS supports a number of
features which are not directly related to efficiency per se. Most notable of
these is implicit mapping of functions over series. Whenever an ordinary Lisp
function is syntactically applied to a series, it is automatically mapped over
the elements of the series.
The following example illustrates implicit mapping. In the function below,
the computation "(lambda (x) (expt (abs x) 3))" is implicitly mapped over the
series of numbers generated by Evector. Implicit mapping of this sort is a
commonly used feature of APL and is extremely convenient.
(defun sum-cube-abs-vect (v)
(Rsum (expt (abs (Evector v)) 3)))
(sum-cube-abs-vect #(1 -2 3)) => (+ 1 8 27) => 36
New series functions can be defined by using the form defunS. The following
example shows how the function Rsum could be defined. More complex forms can
be defined by using the ordinary Common Lisp macro definition facilities to
define macros which create appropriate series expressions.
(defunS Rsum (numbers)
(declare (series numbers))
(reduceS #'+ 0 numbers))
LetS provides two forms (LetS and LetS*) which are analogous to let and
let*. As shown in the example below, These forms can be used to bind both
ordinary variables (e.g., num-obs, mean, and deviation) and series variables
(e.g., ob). Whether or not a variable is a series is determined
by looking at the type of value produced by the expression which computes
the value bound to it.
(defun mean-and-deviation (observations)
(letS* ((ob (Elist observations))
(num-obs (Rlength ob))
(mean (/ (Rsum ob) num-obs))
(deviation (- (/ (Rsum (expt ob 2)) num-obs) (expt mean 2))))
(list mean deviation)))
The complete documentation of LetS compares LetS with the Common Lisp
sequence functions and with the Zeta Lisp Loop macro. LetS supports
essentially all of the functionality of the Loop macro in a style which looks
like sequence functions and which is exactly as efficient as the loop macro.
THE ANCESTRY OF LETS
The LetS package described here is descended from an earlier package of the
same name (See MIT/AIM-680a and "Expressional Loops", Proc. Eleventh ACM
SIGACT-SIGPLAN Symposium on the Principles of Programming Languages, January
1984). The current system differs from the earlier system in a number of
ways. In particular, the new system supports a much wider set of features.
∂28-Mar-86 1436 Fischer.pa@Xerox.COM Re: Predicates for all type specifier symbols
Received: from XEROX.COM by SU-AI.ARPA with TCP; 28 Mar 86 14:35:12 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 28 MAR 86 14:35:19 PST
Date: 28 Mar 86 14:35 PST
From: Fischer.pa@Xerox.COM
Subject: Re: Predicates for all type specifier symbols
In-reply-to: NGALL@G.BBN.COM's message of 28 Mar 86 11:20 EST
To: NGALL@G.BBN.COM
cc: common-lisp@SU-AI.ARPA
Message-ID: <860328-143519-3626@Xerox>
Why do we need any predicate aside from TYPEP?
(ron)
∂28-Mar-86 2029 FAHLMAN@C.CS.CMU.EDU Predicates for all type specifier symbols
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 28 Mar 86 20:28:34 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 28 Mar 86 22:59:11-EST
Date: Fri, 28 Mar 1986 20:16 EST
Message-ID: <FAHLMAN.12194428457.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Predicates for all type specifier symbols
In-reply-to: Msg of 28 Mar 1986 17:35-EST from Fischer.pa at Xerox.COM
It was proposed long ago that we just flush all the specific type
specifiers and just go with Typep. A few pre-existing ones were then
added back in for compatibility with existing Lisps and existing
Lispers. Another ugly compromise, I guess. A similar situation
prevails in SETF, where a couple of old favorites were retained, even
though they are now redundant.
-- Scott
∂29-Mar-86 1255 NGALL@G.BBN.COM Re: Predicates for all type specifier symbols
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 29 Mar 86 12:55:18 PST
Date: 29 Mar 1986 15:54-EST
Sender: NGALL@G.BBN.COM
Subject: Re: Predicates for all type specifier symbols
From: NGALL@G.BBN.COM
To: Fahlman@C.CS.CMU.EDU
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]29-Mar-86 15:54:53.NGALL>
In-Reply-To: <FAHLMAN.12194428457.BABYL@C.CS.CMU.EDU>
Date: Fri, 28 Mar 1986 20:16 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Predicates for all type specifier symbols
In-Reply-To: Msg of 28 Mar 1986 17:35-EST from Fischer.pa at Xerox.COM
Message-ID: <FAHLMAN.12194428457.BABYL@C.CS.CMU.EDU>
It was proposed long ago that we just flush all the specific type
specifiers and just go with Typep. A few pre-existing ones were then
added back in for compatibility with existing Lisps and existing
Lispers. Another ugly compromise, I guess. A similar situation
prevails in SETF, where a couple of old favorites were retained, even
though they are now redundant.
-- Scott
--------------------
What implementations did commonp pre-exist in :-? Also, If we want to
steer away from type-specific predicates and towards TYPEP, why does
DEFSTRUCT create a predicate by default? Also, one disadvantage with
TYPEP is that you have to wrap it up in a lambda-pression in order to
pass it around, i.e., I much prefer #'listp to
#'(lambda (x) (typep x 'list)).
In any case, if we decide to have predicates that always return T and
NIL respectively, (e.g., for KMP condition system proposal) I suggest
that we add the type-specifiers T and NIL to the set of
type-specifiers that have associated predicates, TP and NILP,
repectively.
-- Nick
P.S. any comments on the desirability of the new type-specifiers that I
proposed?
∂29-Mar-86 1354 WHOLEY@C.CS.CMU.EDU Predicates for all type specifier symbols
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 29 Mar 86 13:54:00 PST
Received: ID <WHOLEY@C.CS.CMU.EDU>; Sat 29 Mar 86 16:54:53-EST
Date: Sat, 29 Mar 1986 16:54 EST
Message-ID: <WHOLEY.12194653947.BABYL@C.CS.CMU.EDU>
Sender: WHOLEY@C.CS.CMU.EDU
From: Skef Wholey <Wholey@C.CS.CMU.EDU>
To: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Cc: common-lisp@SU-AI.ARPA
Subject: Predicates for all type specifier symbols
In-reply-to: Msg of 28 Mar 1986 20:16-EST from Scott E. Fahlman <Fahlman>
The old-fashioned type predicates are useful for sequence function tests and
the like. By using the same logic that gets us to the proposed functions TRUE
and FALSE, we can get to the old-fashioned type predicates.
At any rate, they save typing, as does CADDDR (which no one seems interested in
flushing). That the set of such predicates is incomplete calls for the
addition of functions to complete the set, rather than the elimination of all
type predicate functions. Back in the early Common Lisp days, one principal
guiding the design was "brain compataiblity" -- There are some things that will
cause more trouble in the short run due to programmers being unfamiliar with
new names or argument ordering or missing features or different functionality
than can be justified by streamlining the language.
I guarantee that if these functions are not provided, many major pieces of
portable software will define them for themselves, and some superset
implementations will provide them anyway, and porting such software will be
more of a hassle than it should be. I have seen this happen with ASSQ while
porting two systems (OPS-5 and PCL) in two Common Lisps (Symbolics and Spice).
The result is that the portable code now has hacks to define such functions
only if they don't already exist.
HOWEVER, if we were to nuke our old friends LISTP, ATOM, NUMBERP, and so on, we
could introduce something in the spirit of the proposed CONSTANT function to
make :TEST functions a wee bit easier to create.
(defun typefun (type)
#'(lambda (x) (typep x type)))
As with CONSTANT, this needn't cons a new function for each invocation -- it
could return constant functions for the common cases.
--Skef
∂29-Mar-86 1731 FAHLMAN@C.CS.CMU.EDU Predicates for all type specifier symbols
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 29 Mar 86 17:31:03 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 29 Mar 86 20:31:55-EST
Date: Sat, 29 Mar 1986 20:31 EST
Message-ID: <FAHLMAN.12194693455.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Skef Wholey <Wholey@C.CS.CMU.EDU>
Cc: common-lisp@SU-AI.ARPA
Subject: Predicates for all type specifier symbols
In-reply-to: Msg of 29 Mar 1986 16:54-EST from Skef Wholey <Wholey>
I agree that if we aren't going to flush all of these things (and for
compatibility we probably can't), then we ought to complete the set of
predicates for single-symbol type specifiers. I'd leave out T and NIL,
however.
-- Scott
∂29-Mar-86 1852 Moon@SCRC-STONY-BROOK.ARPA Predicates for all type specifier symbols
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 29 Mar 86 18:52:06 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 450265; Sat 29-Mar-86 21:49:21-EST
Date: Sat, 29 Mar 86 21:50 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Predicates for all type specifier symbols
To: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12194693455.BABYL@C.CS.CMU.EDU>
Message-ID: <860329215031.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sat, 29 Mar 1986 20:31 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I agree that if we aren't going to flush all of these things (and for
compatibility we probably can't), then we ought to complete the set of
predicates for single-symbol type specifiers.
Perhaps we ought to re-read the voting documents and discussion from the
era when we got rid of FIXNUMP and so forth before adding any type-specific
predicates.
∂31-Mar-86 0620 greek%bach.decnet@hudson.dec.com Type predicates.
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 31 Mar 86 06:20:17 PST
Date: 31 Mar 86 09:16:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: Type predicates.
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
We need all of the type predicates currently in Common LISP because
removing them would break every program in existence. However, adding
more seems rather silly. We might even say that TYPEP is the preferred
way to check the type of an object, and that the other type predicates
are only retained for compatability.
Some people might object on the grounds that (INTEGERP X) is more
immediately obvious than (TYPEP X 'INTEGER).
- Paul
------
∂31-Mar-86 0707 DCP@ALLEGHENY.SCRC.Symbolics.COM Predicates for types.
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 31 Mar 86 07:06:26 PST
Received: from FIREBIRD.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 10297; Mon 31-Mar-86 10:05:01-EST
Date: Mon, 31 Mar 86 10:05 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: Predicates for types.
To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>, NGALL@G.BBN.COM,
Fischer.pa@Xerox.COM, Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>,
Skef Wholey <Wholey@C.CS.CMU.EDU>,
David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>,
common-lisp <common-lisp@SU-AI.ARPA>
In-Reply-To: The message of 28 Mar 86 12:32-EST from "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>,
<[G.BBN.COM]28-Mar-86 11:20:13.NGALL>,
<860328-143519-3626@Xerox>,
<FAHLMAN.12194428457.BABYL@C.CS.CMU.EDU>,
<[G.BBN.COM]29-Mar-86 15:54:53.NGALL>,
<WHOLEY.12194653947.BABYL@C.CS.CMU.EDU>,
<FAHLMAN.12194693455.BABYL@C.CS.CMU.EDU>,
<860329215031.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <860331100506.8.DCP@FIREBIRD.SCRC.Symbolics.COM>
One reason to have specific predicates is efficiency. This is not just
an implementation detail hidden by the compiler, such as
(typecase foo
(fixnum ...)
(integer ...)
(number ...)
...)
or
(typep foo 'number)
I admit the user should probably use those constructs instead of the -P
predicates and instead let the compiler do the fun. Other constructs,
however, do not lend themselves to this abstraction. Would you rather
type
(count-if #'integerp sequence)
or
(count-if #'(lambda (object) (typep object 'integer)) sequence)
?? In addition to which would you rather type, which would you rather
read in somebody else's code?
∂31-Mar-86 0750 gls@THINK-AQUINAS.ARPA Re: Predicates for all type specifier symbols
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 31 Mar 86 07:48:27 PST
Received: from guido by GODOT.THINK.COM via CHAOS; Mon, 31 Mar 86 10:49:04 est
Date: Mon, 31 Mar 86 10:50 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Re: Predicates for all type specifier symbols
To: Fischer.pa@Xerox.COM, NGALL@G.BBN.COM
Cc: common-lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA
In-Reply-To: <860328-143519-3626@Xerox>
Message-Id: <860331105045.2.GLS@GUIDO.THINK.COM>
Date: 28 Mar 86 14:35 PST
From: Fischer.pa@Xerox.COM
Why do we need any predicate aside from TYPEP?
(ron)
[Sign on a paper towel dispenser] Why take two when one will do?
[Graffito immediately beneath] For gracious living.
We don't need anything beyond TYPEP, but in some cases INTEGERP
or ATOM is easier to recognize.
--Guy
∂31-Mar-86 1134 neches@isi-vaxa.ARPA common-lisp on vaxes under vms?
Received: from ISI-VAXA.ARPA by SU-AI.ARPA with TCP; 31 Mar 86 11:34:03 PST
Received: by isi-vaxa.ARPA (4.12/4.7)
id AA04101; Mon, 31 Mar 86 11:34:57 pst
Message-Id: <8603311934.AA04101@isi-vaxa.ARPA>
Date: 31 Mar 1986 1134-PST (Monday)
To: common-lisp@su-ai.ARPA
From: Neches@ISI-VAXA.ARPA
Subject: common-lisp on vaxes under vms?
A friend of mine is looking for a version of common-lisp
that he could run on a vax under vms. Can anyone tell me who
I could suggest that he contact? He is in a university setting,
and on a low budget, so it would be best if he could find a version
that is either in the public domain or licensed cheaply to
universities. Please reply to Neches@isi-vaxa.arpa. Thanks.
∂31-Mar-86 1215 Daniels.PA@Xerox.COM Re: Predicates for all type specifier symbols
Received: from XEROX.COM by SU-AI.ARPA with TCP; 31 Mar 86 12:15:01 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 31 MAR 86 12:10:28 PST
Date: 31 Mar 86 12:10:03 PST (Monday)
From: Daniels.PA@Xerox.COM
Subject: Re: Predicates for all type specifier symbols
In-reply-to: <[G.BBN.COM]28-Mar-86 11:20:13.NGALL>
To: NGALL@G.BBN.COM
cc: common-lisp@SU-AI.ARPA
Message-ID: <860331-121028-4949@Xerox>
"Also, If we had TP and NILP we would have the TRUE and FALSE functions
that KMP was asking for!"
Not quite: TRUE and FALSE take an arbitrary number of arguments and ignore them all.
-- Andy. --
∂31-Mar-86 1252 NGALL@G.BBN.COM Re: Predicates for all type specifier symbols
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 31 Mar 86 12:48:32 PST
Date: 31 Mar 1986 15:47-EST
Sender: NGALL@G.BBN.COM
Subject: Re: Predicates for all type specifier symbols
From: NGALL@G.BBN.COM
To: Daniels.PA@XEROX.COM
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]31-Mar-86 15:47:31.NGALL>
In-Reply-To: <860331-121028-4949@Xerox>
Date: 31 Mar 86 12:10:03 PST (Monday)
From: Daniels.PA@Xerox.COM
To: NGALL@G.BBN.COM
Subject: Re: Predicates for all type specifier symbols
In-Reply-To: <[G.BBN.COM]28-Mar-86 11:20:13.NGALL>
Message-ID: <860331-121028-4949@Xerox>
"Also, If we had TP and NILP we would have the TRUE and FALSE functions
that KMP was asking for!"
Not quite: TRUE and FALSE take an arbitrary number of arguments and ignore them all.
Oops! You're right. I should have said "we would have the TRUE and FALSE
functions that are sufficient for reducing the 'visual clutter' mentioned
in KMP's error proposal!"
-- Nick
∂31-Mar-86 1330 KMP@SCRC-STONY-BROOK.ARPA predicates for all type specifier symbols
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 31 Mar 86 13:29:59 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 451202; Mon 31-Mar-86 16:07:52-EST
Date: Mon, 31 Mar 86 16:10 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: predicates for all type specifier symbols
To: Daniels.PA@Xerox, NGALL@G.BBN.COM
cc: Common-Lisp@SU-AI
In-Reply-To: <860331-121028-4949@Xerox>
Message-ID: <860331161012.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Actually, the TRUE and FALSE functions I asked for return the constant values
true and false. The TP and NILP functions being proposed happen to constantly
return true and false, respectively, but do not do so because they are directly
defined to do so; they do so because it is a logical consequence of the fact
that all things are of type T and no things are of type NIL. In addition to the
number of args issues that Daniels pointed out, let me make it clear that I
would not be satisfied with these because code written to use them would not be
perspicuous. It would bother me as much as it bothered me to see code in Maclisp
that did:
(AND FOO
(NOT (TERPRI))
(PRINT MESSAGE)
...)
Sure, it was defined in Maclisp that TERPRI returned NIL and PRINT returned T
but there are times when in spite of definition, it just isn't stylistically
appropriate to take advantage of that fact in code that you would want to show
your mother.
While I'm on the subject, let me point out that I consider completeness arguments
for having all possible "-P" type predicates to be weak because it only reinforces
the arbitrary line between system and user code. User-defined types are not
required to have such predicates, and even if they have them, the naming
conventions we defaultly assign do not match. If we required the fixing of the
way predicates were constructed and removed the user's ability to either inhibit
the definition of such predicates or choose an alternate name for such predicates,
then we'd be making progress toward linguistic consistency. As it is, I think
we're just gonna have to settle for the fact that the names that are there are
there for convenience and not for any purist reason. Having accepted that, I
don't see a lot of reason for introducing a lot of new predicates. If there were
particulars that people had found immensely useful in a variety of circumstances,
maybe we could consider adding them on a case-by-case basis. But let's not treat
this as a class-action suit.
∂31-Mar-86 1616 NGALL@G.BBN.COM Re: predicates for all type specifier symbols
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 31 Mar 86 16:16:12 PST
Date: 31 Mar 1986 19:14-EST
Sender: NGALL@G.BBN.COM
Subject: Re: predicates for all type specifier symbols
From: NGALL@G.BBN.COM
To: KMP@SCRC-STONY-BROOK.ARPA
Cc: Daniels.PA@XEROX.COM, Common-Lisp@SU-AI.ARPA
Cc: clerha@SU-AI.ARPA
Message-ID: <[G.BBN.COM]31-Mar-86 19:14:22.NGALL>
In-Reply-To: <860331161012.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Mon, 31 Mar 86 16:10 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
To: Daniels.PA@Xerox, NGALL@G.BBN.COM
Subject: predicates for all type specifier symbols
In-Reply-To: <860331-121028-4949@Xerox>
Message-ID: <860331161012.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Actually, the TRUE and FALSE functions I asked for return the constant values
true and false. The TP and NILP functions being proposed happen to constantly
return true and false, respectively, but do not do so because they are directly
defined to do so; they do so because it is a logical consequence of the fact
that all things are of type T and no things are of type NIL. In addition to the
number of args issues that Daniels pointed out, let me make it clear that I
would not be satisfied with these because code written to use them would not be
perspicuous.
You're right,
:TEST #'true
is more perspicuous than
:TEST #'tp
but I think
:CONDITION #'condition
is the most perspicuous. So we don't need the function TRUE to reduce
visual clutter.
It would bother me as much as it bothered me to see code in Maclisp
that did:
(AND FOO
(NOT (TERPRI))
(PRINT MESSAGE)
...)
Sure, it was defined in Maclisp that TERPRI returned NIL and PRINT returned T
but there are times when in spite of definition, it just isn't stylistically
appropriate to take advantage of that fact in code that you would want to show
your mother.
I don't agree with your analogy to TERPRI. The phrase
:TEST #'tp
means "whatever condition is handed to me is within the set of conditions
that I will deal with". Granted its not as perspicuous as
:TEST #'conditionp
but its not as random as just using any always-true function.
While I'm on the subject, let me point out that I consider completeness arguments
for having all possible "-P" type predicates to be weak because it only reinforces
the arbitrary line between system and user code. User-defined types are not
required to have such predicates, and even if they have them, the naming
conventions we defaultly assign do not match. If we required the fixing of the
way predicates were constructed and removed the user's ability to either inhibit
the definition of such predicates or choose an alternate name for such predicates,
then we'd be making progress toward linguistic consistency. As it is, I think
we're just gonna have to settle for the fact that the names that are there are
there for convenience and not for any purist reason. Having accepted that, I
don't see a lot of reason for introducing a lot of new predicates. If there were
particulars that people had found immensely useful in a variety of circumstances,
maybe we could consider adding them on a case-by-case basis. But let's not treat
this as a class-action suit.
"Class-Action Suit" makes it sound like I'm asking for hundreds of new
predicates. I'm asking for 13.
I doubt that all (even most of?) the existing predicates are
"immensely useful", so why should the few additional ones have to pass
such a test. I would find some of them "useful", e.g., fixnump (I
didn't understand Moon's objection to this one), sequence, and
simple-array.
Also, I like the idea embodied in defstruct: If someone defines a
type, chances are they would find a predicate useful. I think the
same should apply to system defined types.
I guess you prefer the idea embodied in deftype, which does not define
an associated predicate.
-- Nick
∂01-Apr-86 0158 cfry%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU eval-when ambiguity
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 1 Apr 86 01:54:14 PST
Received: from BUDDY.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 1 Apr 86 04:56-EST
Date: Tue, 1 Apr 86 04:54 EST
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
Subject: eval-when ambiguity
To: common-lisp@SU-AI.ARPA
Message-ID: <860401045418.4.CFRY@BUDDY.AI.MIT.EDU>
When compiling a file with a top level call:
(eval-when (load)
(defun foo ()
(a-macro))
)
There seem to be 2 possibilites:
1. The definition gets compiled at compile-file time
and saved to the file in compiled format
2. The list structure of the call is saved to the file
and it's EVALED when the file is loaded.
Semantically, the major difference seems to be the time
of macroexpansion.
I can imagine wanting both functionalities.
Which one is CL defined to do?
How do you get the other functionality?
[keep in mind that the first arg to the eval-when might have
compile or eval in it.]
In CLtL, p 69, the first 2 paragraphs of the eval-when description
are clear and concise. They indicate CL should perform as in 2 above.
The succeeding paragraphs, in an attempt to clarify, do exactly
the opposite.
∂01-Apr-86 0619 greek%bach.decnet@hudson.dec.com EVAL-WHEN
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 1 Apr 86 06:19:17 PST
Date: 1 Apr 86 09:14:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: EVAL-WHEN
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Mr. Fry has begun our bimonthly discussion of EVAL-WHEN (on April 1,
no less). I think, however, that the case of (EVAL-WHEN (LOAD)
(DEFUN...)) is straightforward. When the book says that "the compiler
should arrange to evaluate the forms in the body when the compiled file
... is loaded", it means that the DEFUN should be evaluated to produce
its effect of stashing a function in the symbol's definition. I don't
think anyone meant to imply that the body of the DEFUN had to be
processed in any particular fashion (e.g., macroexpanding it at load
time). But I'll acknowledge that it's not precisely clear.
If you do want the DEFUN to be processed as if it was entered at
top-level, you might do the following, which will produce an interpreted
definition:
(EVAL-WHEN (LOAD)
(EVAL '(DEFUN ...))
)
A related question is what to do with other sorts of top-level forms,
not DEFUNs or DEFMACROS. Some LISPs have a (perhaps secret) switch
which determines whether the compiler dumps anonymous compiled functions
or dumps the lists and interprets them at load time. There may be
demantic differences resulting from the choice.
A couple of other questions have been asked before and never really
answered. Are EVAL-WHENs allowed down in the guts of a function or
macro and what do they mean there? Also, would it clarify things if we
acknowledged the fourth EVAL-WHEN situation, that of the compiler
digesting a definition without actually evaluating it? This occurs, for
example, when the compiler sees a DEFMACRO. It doesn't evaluate it per
se, but it does digest it enough to be able to expand future macro calls.
It's not sufficient to say that DEFMACRO is a special case and the
compiler always looks at it, because the compiler doesn't look if it's
wrapped in an (EVAL-WHEN (EVAL) ...). This implies that there is some
secret situation that has been left out of the list.
- Paul
------
∂01-Apr-86 0836 gls@THINK-AQUINAS.ARPA [CAL@THINK-AQUINAS.ARPA: declarations]
Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 1 Apr 86 08:36:44 PST
Received: from ZACHARY.THINK.COM by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 18195; Tue 1-Apr-86 11:41:20-EST
Date: Tue, 1 Apr 86 11:38 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: [CAL@THINK-AQUINAS.ARPA: declarations]
To: common-lisp@SU-AI.ARPA
cc: gls@THINK-AQUINAS.ARPA
Message-ID: <860401113847.5.GLS@ZACHARY.THINK.COM>
Return-path: <@GODOT.THINK.COM:CAL@THINK-AQUINAS.ARPA>
Received: from GODOT.THINK.COM by THINK-AQUINAS.ARPA via INTERNET with SMTP id 18147; 1 Apr 86 01:47:53-EST
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Tue, 1 Apr 86 01:43:38 est
Date: Tue, 1 Apr 86 01:45 EST
From: Cliff Lasser <CAL@THINK-AQUINAS.ARPA>
Subject: declarations
To: GLS@THINK-AQUINAS.ARPA
Cc: Lispm-users@GODOT.THINK.COM
Message-Id: <860401014524.3.CAL@THINK-JEHOSEPHAT.ARPA>
If I were to do:
(PROCLAIM '(DECLARATION TARGET-LANGUAGE))
(PROCLAIM '(TARGET-LANGUAGE ADA))
would I be able to write code that would uncover that declaration. I
couldn't find anything helpful in the CL manual.
(ps: This would be very useful)
∂01-Apr-86 0846 gls@THINK-AQUINAS.ARPA [rose@GODOT.THINK.COM: option for recovering proclamations]
Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 1 Apr 86 08:45:56 PST
Received: from ZACHARY.THINK.COM by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 18203; Tue 1-Apr-86 11:49:51-EST
Date: Tue, 1 Apr 86 11:47 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: [rose@GODOT.THINK.COM: option for recovering proclamations]
To: common-lisp@SU-AI.ARPA
cc: gls@THINK-AQUINAS.ARPA
Message-ID: <860401114720.7.GLS@ZACHARY.THINK.COM>
Date: 01 Apr 86 09:15:43 EST (Tue)
From: rose@think.THINK.COM
You could shadow LISP:PROCLAIM with STARLISP:PROCLAIM, making the latter
a macro which squirrels away its info, and also expands to a LISP:PROCLAIM.
Package hackery to make this happen:
(SHADOW 'LISP:PROCLAIM 'STARLISP-INTERNALS)
(EXPORT 'STARLISP-INTERNALS::PROCLAIM 'STARLISP-INTERNALS)
(DEFMACRO STARLISP-INTERNALS:PROCLAIM (DECLARATION)
`(PROGN (GOBBLE ',DECLARATION) (LISP:PROCLAIM ,DECLARATION)))
(DEFMACRO USE-STARLISP ()
`(PROGN (USE-PACKAGE 'STARLISP) (IMPORT 'STARLISP-INTERNALS:PROCLAIM)))
;; And so:
(IN-PACKAGE 'MY-APPLICATION)
(USE-STARLISP)
(PROCLAIM ...)
Small reward. You still have to code-walk for the (DECLARE...) forms.
∂01-Apr-86 1428 Gregor.pa@Xerox.COM Common Lisp Problems - Can't write a code walker
Received: from XEROX.COM by SU-AI.ARPA with TCP; 1 Apr 86 14:27:21 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 01 APR 86 14:28:07 PST
Date: 1 Apr 86 13:27 PST
From: Gregor.pa@Xerox.COM
Subject: Common Lisp Problems - Can't write a code walker
To: Common-Lisp@SU-AI.ARPA
cc: Gregor.pa@Xerox.COM
Message-ID: <860401-142807-1904@Xerox>
This is the first of a few messages describing the problems I have had
with Common Lisp while writing Portable Common Loops. This message
lists some reasons why it is *hard* to write a portable code walker in
Common Lisp. This message doesn't propose detailed solutions to these
problems, it mostly just states the problems.
- You can't query to find the current state of global proclamations.
Specifically, you can't ask if a variable has been declared globally
special. This doesn't make is impossible to write a code walker since
you can write a little piece of code to test if a variable is special,
but it is a nuisance. This piece of code from PCL shows the problem:
#-(or Symbolics Xerox TI VaxLisp KCL LMI)
(defvar *globally-special-variables* ())
(defun variable-globally-special-p (symbol)
#+(or Symbolics Lucid TI LMI) (get symbol 'special)
#+Xerox (member symbol globalvars)
#+VaxLisp (get symbol 'system::globally-special)
#+KCL (proclamation `(special ,symbol))
#-(or Symbolics Lucid TI LMI Xerox VaxLisp KCL)
(or (not (null (member symbol *globally-special-variables* :test
#'eq)))
(when (eval `(flet ((ref () ,symbol))
(let ((,symbol '#,(list nil)))
(and (boundp ',symbol) (eq ,symbol (ref))))))
(push symbol *globally-special-variables*)
t)))
KCL has a function called PROCLAMATION which takes the same arguments as
proclaim and returns t if that PROCLAIM is in effect. Perhaps Common
Lisp should have a function called PROCLAIMP which works the same way as
the KCL proclamation function.
2- Lack of clarity and lack of functionality with regard to
environments.
Common Lisp doesn't *clearly* provide a mechanism to make an environment
that has certaion function macro or lexical variable bindings. Or to
make an environment that is based on some existing environment but has
extra bindings. Or to query an environment about its bindings. In I
tried to get around this problem with a weird evalhook macroexpand hack.
But it isn't completely portable. CommonLisp needs defined mechanisms
for manipulating these environment structures.
3- Implementations have special forms in their extended lisps that are
not Common Lisp special forms. I don't know if there is anything we can
do about this, but I thought I would mention it. (I suppose we could
agree on a common syntax for defining code walker templates and a common
mechanism for retrieving them but that doesn't seem too likely).
∂02-Apr-86 0754 kempf%hplabsc@hplabs.ARPA Re:Common Lisp Problems-Can't write a code walker
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 2 Apr 86 07:54:28 PST
Received: from hplabsc by hplabs.ARPA ; Wed, 2 Apr 86 07:53:26 pst
Received: by hplabsc ; Wed, 2 Apr 86 07:55:08 pst
Date: Wed, 2 Apr 86 07:55:08 pst
From: Jim Kempf <kempf%hplabsc@hplabs.ARPA>
Message-Id: <8604021555.AA05471@hplabsc>
To: common-lisp@su-ai.ARPA
Subject: Re:Common Lisp Problems-Can't write a code walker
Cc: snyder@hplabsc
I'll be interested in seeing further problems that arose with
writing a code walker for Portable Common Loops. Some of the
problems mentioned in the original posting were addressed
in a proposal for modifications to Common Lisp which we
felt were needed to portably implement CommonObjects.
Alan Snyder presented the document at the December Common Lisp
meeting. In particular, querying the environment object
passed to macros for information on declarations was mentioned.
CommonObjects doesn't do code-walking, since we have an extension
to our Common Lisp which allows us to establish macro-like
substitutions for symbols (a kind of symbol macro), that was
needed in order to implement instance variables with proper
scoping. I think that being able to easily implement a portable
code-walker in Common Lisp is generally desirable, however.
Jim Kempf kempf@hplabs
∂02-Apr-86 0819 greek%bach.decnet@hudson.dec.com The Environment
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 2 Apr 86 08:19:16 PST
Date: 2 Apr 86 11:07:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: The Environment
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Gregor has pointed out some of the many problems with writing programs
that need to understand the current global environment. There are
additional problems caused by the separation of global environment from
compilation environment. Not that we all agree on how that separation
should work.
Do y'all think we could get enough concensus on how the environment
should look to the user so that we could add the appropriate support
functions to Common LISP? This would lock in at least basic concepts,
making it hard to experiment with radically different environments. But
that loss might be well worth the gains.
If a concensus is possible, I'd be willing to make a rough proposal
concerning the representation of symbols attributes and separation of
global and compiler environments.
- Paul
------
∂02-Apr-86 0856 DCP@ALLEGHENY.SCRC.Symbolics.COM The Environment
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 2 Apr 86 08:48:37 PST
Received: from FIREBIRD.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 10890; Wed 2-Apr-86 11:49:13-EST
Date: Wed, 2 Apr 86 11:49 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: The Environment
To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>,
common-lisp <common-lisp@SU-AI.ARPA>
In-Reply-To: The message of 2 Apr 86 11:07-EST from "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Message-ID: <860402114909.3.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: 2 Apr 86 11:07:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Gregor has pointed out some of the many problems with writing programs
that need to understand the current global environment. There are
additional problems caused by the separation of global environment from
compilation environment. Not that we all agree on how that separation
should work.
Do y'all think we could get enough concensus on how the environment
should look to the user so that we could add the appropriate support
functions to Common LISP? This would lock in at least basic concepts,
making it hard to experiment with radically different environments. But
that loss might be well worth the gains.
If a concensus is possible, I'd be willing to make a rough proposal
concerning the representation of symbols attributes and separation of
global and compiler environments.
This is the wrong direction, since it imposes restrictions on the format
of the environment. What would be OK is to define an interface which
imposes requirements of the environment. Define the functionality you
need, invent some function names, but don't go near the format of the
environment.
∂02-Apr-86 0942 greek%bach.decnet@hudson.dec.com The Environment
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 2 Apr 86 09:40:16 PST
Date: 2 Apr 86 12:27:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: The Environment
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Whew, I have to be careful what I imply in my messages. I certainly
wasn't suggesting that we define the internal format of the environment,
only how the user sees it in terms of interface. Mr. Plummer and I
agree on this point.
Still, do you think we can all agree on the interface, and thus the
semantics?
- Paul
------
∂02-Apr-86 1051 DCP@ALLEGHENY.SCRC.Symbolics.COM The Environment
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 2 Apr 86 10:41:29 PST
Received: from FIREBIRD.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 10927; Wed 2-Apr-86 13:41:44-EST
Date: Wed, 2 Apr 86 13:41 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: The Environment
To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>,
common-lisp <common-lisp@SU-AI.ARPA>
In-Reply-To: The message of 2 Apr 86 12:27-EST from "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Message-ID: <860402134140.9.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: 2 Apr 86 12:27:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Whew, I have to be careful what I imply in my messages. I certainly
wasn't suggesting that we define the internal format of the environment,
only how the user sees it in terms of interface. Mr. Plummer and I
agree on this point.
Still, do you think we can all agree on the interface, and thus the
semantics?
I think we should give it a try. I think what you will find are three
things:
-1- Things everybody agrees on, e.g.,
.defun variable-defined-p symbol &optional env
returns a keyword which is the usage of the variable, one of
NIL (unknown)
:SPECIAL
:LEXICAL
:CONSTANT
<other> (e.g., :INSTANCE)
-2- Things not everybody agrees on
-3- Things which are down-and-out hard, e.g.,
"Which PROG is belongs with this GO-TAG?"
I just realized this gets more complicated because there are two classes
of programs that are using something called an 'environment' for
potentially different reasons. One class is the interpreter, which does
know something about GO tags, but the source code of the PROG isn't
necessarily in the environment. The other class is a code walker or
compiler, which uses a much higher degree of bookkeeping and annotation.
∂02-Apr-86 2102 smh@mit-ems.ARPA packages, lexical variables, and compiling
Received: from MIT-EMS.ARPA by SU-AI.ARPA with TCP; 2 Apr 86 21:02:40 PST
Received: by mit-ems.ARPA (4.12/4.8) id AA06396; Thu, 3 Apr 86 00:01:56 est
Date: Thu, 3 Apr 86 00:01:56 est
From: Steven Haflich <smh@mit-ems.ARPA>
Message-Id: <8604030501.AA06396@mit-ems.ARPA>
To: common-lisp@suai
Subject: packages, lexical variables, and compiling
Consider the file foo.lisp:
(IN-PACKAGE "MYPACKAGE")
(DEFUN FOO (X)
(LET ((X-PLUS-1 (1+ X)))
(LIST X X-PLUS-1)))
Loading foo.lisp into any common lisp has the side effect of creating
package MYPACKAGE if it does not yet exist, and also creating symbols
MYPACKAGE::FOO, MYPACKAGE::X, and MYPACKAGE::X-PLUS-1 if any of these
do not exist. So much is clear.
If foo.lisp is compiled to produce foo.bin, and foo.bin is later loaded
into a different lisp world, clearly package MYPACKAGE and symbol
MYPACKAGE:FOO must be created if they do not yet exist. But what about
symbols MYPACKAGE::X and MYPACKAGE::X-PLUS-1 ?
The existence of symbols naming these lexical variables is not required
for execution of the function. (A clever compiler could even optimize
X-PLUS-1 away.) Still, it is easy for a program to tell whether these
symbols exist, and it is possible to construct package interlocutions
which will fail depending on whether or not the symbols are created.
There are three possibilities:
1 - CLtL requires that the symbols are created (although some
implementations fail to do so), preserving interpreter-compiler
consistency.
2 - CLtL requires that the symbols not be created, which saves storage
but loses interpreter-compiler consistency.
3 - CLtL explicitly leaves it up to the implementation.
Unless I have missed something, CLtL is silent on the matter. This is
*not* quite the same as leaving it up to the implementation. Should
the language definition be more specific?
∂03-Apr-86 0619 greek%bach.decnet@hudson.dec.com Lexical variables and compilation.
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 3 Apr 86 06:19:13 PST
Date: 3 Apr 86 09:03:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: Lexical variables and compilation.
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
A couple of comments on Mr. Haflich's little program.
First of all, I don't think it's absolutely clear that the compiler is
obliged to create MYPACKAGE if it can somehow avoid it. After all, it's
really nice if the compiler leaves the global environment alone.
Implementation of this nicety is another matter, however.
Secondly, I don't think it's so easy for the interpreter to detect the
presence of the lexical symbols. At least not in a correct program.
We've carefully constrained all the symbol-hacking functions to work
only on the dynamic (global) aspects of symbols. Therefore the compiler
need not create real symbols for lexical variables.
- Paul
------
∂03-Apr-86 0750 gls@THINK-AQUINAS.ARPA Common Lisp Problems - Can't write a code walker
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 3 Apr 86 07:50:12 PST
Received: from katherine by GODOT.THINK.COM via CHAOS; Thu, 3 Apr 86 10:50:45 est
Date: Thu, 3 Apr 86 10:52 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Common Lisp Problems - Can't write a code walker
To: Gregor.pa@Xerox.COM, Common-Lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <860401-142807-1904@Xerox>
Message-Id: <860403105214.4.GLS@THINK-KATHERINE.ARPA>
Date: 1 Apr 86 13:27 PST
From: Gregor.pa@Xerox.COM
This is the first of a few messages describing the problems I have had
with Common Lisp while writing Portable Common Loops....
...
3- Implementations have special forms in their extended lisps that are
not Common Lisp special forms. I don't know if there is anything we can
do about this, but I thought I would mention it. (I suppose we could
agree on a common syntax for defining code walker templates and a common
mechanism for retrieving them but that doesn't seem too likely).
Such implementations are in violation of the Common Lisp specification.
Page 57 of CLtL is very clear about this. An implementation of Common
Lisp is NOT free simply to randomly add a new special form as an
"extension"; it must also provide an equivalent macro definition so that
MACROEXPAND may be used to get rid of it for purposes of program
analysis.
∂03-Apr-86 0754 gls@THINK-AQUINAS.ARPA [JAR@MC.LCS.MIT.EDU: changes]
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 3 Apr 86 07:54:26 PST
Received: from katherine by GODOT.THINK.COM via CHAOS; Thu, 3 Apr 86 10:55:00 est
Date: Thu, 3 Apr 86 10:56 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: [JAR@MC.LCS.MIT.EDU: changes]
To: common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
Message-Id: <860403105630.5.GLS@THINK-KATHERINE.ARPA>
From the SCHEME mailing list:
Date: Tue, 1 Apr 86 21:42:41 EST
From: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
To: RRRS-AUTHORS@MC.LCS.MIT.EDU
Message-Id: <[MC.LCS.MIT.EDU].869021.860401.JAR>
I intend to add all the hyperbolic trig functions to Scheme. Also, the
gamma function, Bessel functions, and Legendre polynomials. I use these
all the time and don't know how anyone gets by without them.
I think Scheme numbers are really ad hoc. The ring should be a required
argument to +, *, etc. so that they know where the answer should come
from. (E.g. (+ 4 7 (MOD Z 5)) ==> 1.) Scheme should support arithmetic
mod N, polynomial arithmetic, and arithmetic in arbitrary algebraic
number fields. Complex number fall out as a special case:
(SQRT -1 (MOD (POLY R) (LAMBDA (X) (+ (* X X) 1 R)))) ==> 1i
This should be easy to implement.
I don't see why we need all these random special forms. For example,
there's no need to have QUOTE or LAMBDA. We can write
(SET! (X Y Z) (+ X (* Y Z N) N))
instead of
(LAMBDA (X Y Z) (+ X (* Y Z N) N)).
No ambiguity will result because if the first thing is a list then
obviously the expression can't be an assignment. Similarly, we should
be writing
(SET! (D #(A (B C) 4)))
instead of
(QUOTE (D #(A (B C) 4)))
because what would one-argument SET! mean?
I don't understand why there's no existential quantifer in Scheme.
For example, I often find myself wanting to write
(EXISTS (X) (AND (MEMQ X L1) (MEMQ X L2)))
to find out whether the lists L1 and L2 intersect.
If we have first-class continuations I don't see any reason why we
shouldn't have first-class stores also. E.g.
(LET ((Z (CONS 1 2)))
(CALL-WITH-CURRENT-STORE
(LAMBDA (S)
(SET-CAR! Z 3)
(LIST (CAR Z) (S (LAMBDA () (CAR Z)))))))
==> (3 1)
And while we're on the subject of modules, why don't we just adopt
Common Lisp's package system wholesale? It's really useful and elegant.
Also Zetalisp's LOOP construct is really good.
I'll put all these features in the report (Penguin Books has already
expressed interest, by the way) unless people send me enough money.
Modestly,
Jonathan Rees
Editor
∂03-Apr-86 0859 DCP@SCRC-RIVERSIDE.ARPA packages, lexical variables, and compiling
Received: from SCRC-RIVERSIDE.ARPA by SU-AI.ARPA with TCP; 3 Apr 86 08:59:02 PST
Received: from FIREBIRD.SCRC.Symbolics.COM by SCRC-RIVERSIDE.ARPA via CHAOS with CHAOS-MAIL id 82729; Thu 3-Apr-86 11:59:29-EST
Date: Thu, 3 Apr 86 11:58 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: packages, lexical variables, and compiling
To: Steven Haflich <smh@MIT-EMS.ARPA>,
"BACH::GREEK" <greek%bach.decnet@hudson.dec.com>,
common-lisp@SU-AI.ARPA
In-Reply-To: <8604030501.AA06396@mit-ems.ARPA>,
The message of 3 Apr 86 09:03-EST from "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Message-ID: <860403115830.7.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Thu, 3 Apr 86 00:01:56 est
From: Steven Haflich <smh@mit-ems.ARPA>
[Bottom line: I don't think this has anything to do with the language.
Instead, I think we are slopping over into program environment issues
(again).]
Consider the file foo.lisp:
(IN-PACKAGE "MYPACKAGE")
(DEFUN FOO (X)
(LET ((X-PLUS-1 (1+ X)))
(LIST X X-PLUS-1)))
Loading foo.lisp into any common lisp has the side effect of creating
package MYPACKAGE if it does not yet exist, and also creating symbols
MYPACKAGE::FOO, MYPACKAGE::X, and MYPACKAGE::X-PLUS-1 if any of these
do not exist. So much is clear.
If foo.lisp is compiled to produce foo.bin, and foo.bin is later loaded
into a different lisp world, clearly package MYPACKAGE and symbol
MYPACKAGE:FOO must be created if they do not yet exist. But what about
symbols MYPACKAGE::X and MYPACKAGE::X-PLUS-1 ?
The symbolics implementation will create the symbols MYPACKAGE::X and
MYPACKAGE::X-PLUS-1. They are stored in something called the
debugging-info info. The function ARGLIST (not part of CL, one of our
extensions) will pluck the arglist stored in the debugging-info. In
addition, it is possible to declare what the values are; any symbols
there will be in the resulting environment and ARGLIST will also return
them as the second value. Furthermore, X-PLUS-1 will be stored in a
part of the debugging-info that the debugger can find. Thus if there
was an error, the debugger would know that X-PLUS-1 not only IS a
variable, but where it is (on the stack, in a lexical environment,
whatever) and actually >>build an environment that has the current
lexical state of the function in it<< and use that environment for the
read-eval-print loop. What does this have to do with CLtL?? Absolutely
NOTHING!
The existence of symbols naming these lexical variables is not required
for execution of the function. (A clever compiler could even optimize
X-PLUS-1 away.) Still, it is easy for a program to tell whether these
symbols exist, and it is possible to construct package interlocutions
which will fail depending on whether or not the symbols are created.
There are three possibilities:
1 - CLtL requires that the symbols are created (although some
implementations fail to do so), preserving interpreter-compiler
consistency.
This is not needed for simple systems that do not have a lexical
debugger or something like the ARGLIST function. It may be a bit tricky
for those systems that do renames of local variables and functions (as
discussed in the scoping problems of inlinifying FLET and LABELS).
2 - CLtL requires that the symbols not be created, which saves storage
but loses interpreter-compiler consistency.
All implementations that include a somewhat powerful programming
environment will therefore be incompatible with CLtL.
3 - CLtL explicitly leaves it up to the implementation.
This gets my vote.
Unless I have missed something, CLtL is silent on the matter. This is
*not* quite the same as leaving it up to the implementation. Should
the language definition be more specific?
Maybe yes, maybe no. I vote no for the reasons stated above. I think
the real question is this: What programs will work incorrectly if they
depend on package non-polution? Isn't that what you are really worried
about? X and X-PLUS-1 will not have a global value nor a global
definition, nor a property list. It is as if I typed 'X and 'X-PLUS-1
at the interpreter. Typing at READ (probably of the read-eval-print
loop) will either use existing symbols, create new ones if you are
writing new code, or >>create new ones if you happen to make a typo<<.
Are you careful to UNINTERN your typos?
Date: 3 Apr 86 09:03:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
A couple of comments on Mr. Haflich's little program.
First of all, I don't think it's absolutely clear that the compiler is
obliged to create MYPACKAGE if it can somehow avoid it. After all, it's
really nice if the compiler leaves the global environment alone.
Implementation of this nicety is another matter, however.
I don't think this is what Steven Haflich meant, or at least said. He
said the compiler had to cause MYPACKAGE to be created >>in the lisp
environment the compiled file is later loaded into<<.
Secondly, I don't think it's so easy for the interpreter to detect the
presence of the lexical symbols. At least not in a correct program.
We've carefully constrained all the symbol-hacking functions to work
only on the dynamic (global) aspects of symbols. Therefore the compiler
need not create real symbols for lexical variables.
I agree with this except for when you "enter the debugger," whatever
that means in various systems. In the Symbolics implementation, it
means quite a bit as I stated above. The program is correct, and the
read-eval-print loop (what I think you mean by the interpreter) DOES get
the lexical symbols into its environment. Again, the debugger is not
part of CLtL, and therefore CLtL says nothing and can say nothing about
its 'correctness'.
∂03-Apr-86 0953 DD60@A.CS.CMU.EDU internal symbol preservation
Received: from A.CS.CMU.EDU by SU-AI.ARPA with TCP; 3 Apr 86 09:53:06 PST
Date: Thu, 3 Apr 86 12:48 EST
From: David.Dill@A.CS.CMU.EDU (C410DD60)
To: common-lisp@SU-AI.ARPA
Subject: internal symbol preservation
Message-Id: <03Apr86.124832.DD60@A.CS.CMU.EDU>
"::" should be regarded as a convenience feature of the programming
environment, and should not be used in programs. Internal symbols are
internal because they are not supposed to be accessed from outside of
the package. The obvious right thing is that a common lisp
implementation should not feel obliged to keep internal symbols around
just so they can be accessed from outside of the package. Early drafts
of the package chapter said this, but apparently this was changed as
one of many unimprovements.
∂03-Apr-86 1034 Gregor.pa@Xerox.COM Re: packages, lexical variables, and compiling
Received: from XEROX.COM by SU-AI.ARPA with TCP; 3 Apr 86 10:33:29 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 03 APR 86 10:31:45 PST
Date: 3 Apr 86 10:32 PST
From: Gregor.pa@Xerox.COM
Subject: Re: packages, lexical variables, and compiling
In-reply-to: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>'s message of Thu,
3 Apr 86 11:58 EST
To: DCP@SCRC-QUABBIN.ARPA
cc: smh@MIT-EMS.ARPA, greek%bach.decnet@hudson.dec.com,
common-lisp@SU-AI.ARPA
Message-ID: <860403-103145-1391@Xerox>
I think there are two answers to "Haflich's little program".
Answer 1:
Any program that depends on the order that various symbols are interned
to work correctly should do so explicitly. At the beginning of the
program there should be all the make-packages, shadows and lists of
symbols to be interned in the correct order.
To depend on the order that various symbols are loaded implicitly (i.e.
by depending on the order in which functions which use those symbols are
loaded) is just asking for trouble.
Answer 2:
Programmers should be allowed to assume that "as much as is possible"
loading a compiled file and loading the source file have the same
effect.
I guess I believe both of these answers, and so I think CLtL should
require that the symbols be interned. But I can't think of a reasonable
coding style that would *really* depend on this feature.
P.S. Option 2, "CLtL requires that the symbols not be created",
clearly doesn't make any sense at all for all the reasons mentioned by
DCP and other reasons as well.
∂03-Apr-86 1041 DCP@ALLEGHENY.SCRC.Symbolics.COM [JAR@MC.LCS.MIT.EDU: changes]
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 3 Apr 86 10:41:24 PST
Received: from FIREBIRD.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 11125; Thu 3-Apr-86 13:41:35-EST
Date: Thu, 3 Apr 86 13:41 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: [JAR@MC.LCS.MIT.EDU: changes]
To: Guy Steele <gls@THINK-AQUINAS.ARPA>, common-lisp@SU-AI.ARPA,
JAR@MIT-MC.ARPA
In-Reply-To: <860403105630.5.GLS@THINK-KATHERINE.ARPA>
Message-ID: <860403134125.0.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Thu, 3 Apr 86 10:56 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
From the SCHEME mailing list:
Date: Tue, 1 Apr 86 21:42:41 EST
From: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
To: RRRS-AUTHORS@MC.LCS.MIT.EDU
Message-Id: <[MC.LCS.MIT.EDU].869021.860401.JAR>
I intend to add all the hyperbolic trig functions to Scheme. Also, the
gamma function, Bessel functions, and Legendre polynomials. I use these
all the time and don't know how anyone gets by without them.
I never use them, but Chebychev are used all the time for generating FM
modulated audio waves.
I think Scheme numbers are really ad hoc. The ring should be a required
argument to +, *, etc. so that they know where the answer should come
from. (E.g. (+ 4 7 (MOD Z 5)) ==> 1.)
That's not the way to do it at all. The right way to do it is extend
numbers, not functions. That leaves + unchanged. Coersion rules apply,
and error checking is in force. For example, the way you do the above
is not
(+ 4 7 (mod z 5))
but rather
(+ (coerce 4 '(mod 5)) (coerce 7 '(mod 5))) => #<1 mod 5>
Coersion lets you do
(+ (coerce 4 '(mod 5)) 7)
to get the same answer, but
(+ (coerce 4 '(mod 5)) (coerce 7 '(mod 6)))
is an error because of incompatible moduli.
Scheme should support arithmetic
mod N, polynomial arithmetic, and arithmetic in arbitrary algebraic
number fields. Complex number fall out as a special case:
(SQRT -1 (MOD (POLY R) (LAMBDA (X) (+ (* X X) 1 R)))) ==> 1i
Again, don't extend arithmetic, extend numbers:
(sqrt (coerce -1 <whatever>))
This should be easy to implement.
I don't see why we need all these random special forms. For example,
there's no need to have QUOTE or LAMBDA. We can write
(SET! (X Y Z) (+ X (* Y Z N) N))
instead of
(LAMBDA (X Y Z) (+ X (* Y Z N) N)).
No ambiguity will result because if the first thing is a list then
obviously the expression can't be an assignment. Similarly, we should
be writing
(SET! (D #(A (B C) 4)))
instead of
(QUOTE (D #(A (B C) 4)))
because what would one-argument SET! mean?
I like this!
I don't understand why there's no existential quantifer in Scheme.
For example, I often find myself wanting to write
(EXISTS (X) (AND (MEMQ X L1) (MEMQ X L2)))
to find out whether the lists L1 and L2 intersect.
Doesn't scheme support prolog YET?
If we have first-class continuations I don't see any reason why we
shouldn't have first-class stores also. E.g.
(LET ((Z (CONS 1 2)))
(CALL-WITH-CURRENT-STORE
(LAMBDA (S)
(SET-CAR! Z 3)
(LIST (CAR Z) (S (LAMBDA () (CAR Z)))))))
==> (3 1)
And while we're on the subject of modules, why don't we just adopt
Common Lisp's package system wholesale? It's really useful and elegant.
Also Zetalisp's LOOP construct is really good.
I'll put all these features in the report (Penguin Books has already
expressed interest, by the way) unless people send me enough money.
Modestly,
Jonathan Rees
Editor
∂03-Apr-86 1214 DICK%OZ.AI.MIT.EDU@AI.AI.MIT.EDU
Received: from AI.AI.MIT.EDU by SU-AI.ARPA with TCP; 3 Apr 86 12:14:01 PST
Date: Thu, 3 Apr 1986 15:02 EST
Message-ID: <DICK.12195944161.BABYL@MIT-OZ>
Sender: DICK%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
From: Dick@MC.LCS.MIT.EDU
To: common-lisp@SU-AI.ARPA
A few days ago I sent out a message about LetS. Apparently because it
was too long, it did not get through to all of the recipients. I am including
a shortened form of the message below. I apologize to all the people who are
getting this twice.
Dick Waters
SHORTENED LETS MESSAGE
This message advertises a Common Lisp macro package called LetS (rhymes with
lettuce) which it is hoped will become a standard iteration facility in Common
Lisp. LetS makes it possible to write a wide class of algorithms which are
typically written as loops in a functional style which is similar to
expressions written with the Common Lisp sequence functions. LetS supports a
number of features which make LetS expressions more expressive than sequence
expressions. However, the key feature of LetS is that every LetS expression is
automatically transformed into an efficient iterative loop. As a result,
unlike sequence expressions, LetS expressions are just as efficient as the
traditional loop expressions they replace.
Extensive documentation of LetS is in the file "DICK;LETSD >" on the
MIT-AI machine. You are invited to read this documentation and make
comments on it. I am interested in getting as wide a feedback as
possible. If you cannot access the documentation file directly, send
me your US mail address and I will mail you a copy.
After an initial testing and feedback period, a final version of LetS which
runs under all Common Lisps will be created along with formal documentation.
This should happen within a couple of months.
The following is a couple of examples of using LetS
This sums up the positive elements in a vector.
(defun sum-pos-vect-lets (v)
(Rsum (Tplusp (Evector v))))
Automatic mapping is used for ordinary fns applied to series of values.
(defun sum-cube-abs-vect (v)
(Rsum (expt (abs (Evector v)) 3)))
(sum-cube-abs-vect #(1 -2 3)) => (+ 1 8 27) => 36
New series functions can be defined by using the form defunS.
(defunS Rsum (numbers)
(declare (series numbers))
(reduceS #'+ 0 numbers))
LetS provides two forms (LetS and LetS*) which are analogous to let and let*.
(defun mean-and-deviation (observations)
(letS* ((ob (Elist observations))
(num-obs (Rlength ob))
(mean (/ (Rsum ob) num-obs))
(deviation (- (/ (Rsum (expt ob 2)) num-obs) (expt mean 2))))
(list mean deviation)))
∂03-Apr-86 1230 greek%bach.decnet@hudson.dec.com Excuse me?
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 3 Apr 86 12:30:01 PST
Date: 3 Apr 86 15:08:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: Excuse me?
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
You don't really mean that all of the lexical variables in a program
should be interned when the fastload file is loaded. Do you?
- Paul
------
∂03-Apr-86 1609 Moon@SCRC-STONY-BROOK.ARPA EVAL-WHEN
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 3 Apr 86 16:06:58 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 454886; Thu 3-Apr-86 18:26:12-EST
Date: Thu, 3 Apr 86 18:23 -EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: EVAL-WHEN
To: Common-Lisp@SU-AI.ARPA
In-Reply-To: The message of 1 Apr 86 09:14-EST from "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Message-ID: <860403182353.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 1 Apr 86 09:14:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Mr. Fry has begun our bimonthly discussion of EVAL-WHEN (on April 1,
no less). I think, however, that the case of (EVAL-WHEN (LOAD)
(DEFUN...)) is straightforward. When the book says that "the compiler
should arrange to evaluate the forms in the body when the compiled file
... is loaded", it means that the DEFUN should be evaluated to produce
its effect of stashing a function in the symbol's definition. I don't
think anyone meant to imply that the body of the DEFUN had to be
processed in any particular fashion (e.g., macroexpanding it at load
time). But I'll acknowledge that it's not precisely clear.
I agree with you. EVAL-WHEN is intended to control when the normal processing
of its body is done and is not intended to imply that that processing is done
by the function EVAL. The choice of name is perhaps poor.
If you do want the DEFUN to be processed as if it was entered at
top-level, you might do the following, which will produce an interpreted
definition:
(EVAL-WHEN (LOAD)
(EVAL '(DEFUN ...))
)
EVAL of a quoted expression is the way I tell people to do it, however
I don't think the Common Lisp language guarantees that the compiler is
not smart enough to figure out what it thought you meant and compile the
defun anyway. In fact I know of no way that is guaranteed to produce an
interpreted definition. Perhaps this is good, since I believe there are
some implementations that don't have an interpreter, but simply compile
everything.
A related question is what to do with other sorts of top-level forms,
not DEFUNs or DEFMACROS. Some LISPs have a (perhaps secret) switch
which determines whether the compiler dumps anonymous compiled functions
or dumps the lists and interprets them at load time. There may be
demantic differences resulting from the choice.
See below.
A couple of other questions have been asked before and never really
answered. Are EVAL-WHENs allowed down in the guts of a function or
macro and what do they mean there?
The discussion on page 66 that everybody hates was intended to rule out
EVAL-WHEN inside the guts of a function or a macro. I cannot think of
a meaningful interpretation of EVAL-WHEN in this position.
Also, would it clarify things if we
acknowledged the fourth EVAL-WHEN situation, that of the compiler
digesting a definition without actually evaluating it? This occurs, for
example, when the compiler sees a DEFMACRO. It doesn't evaluate it per
se, but it does digest it enough to be able to expand future macro calls.
It's not sufficient to say that DEFMACRO is a special case and the
compiler always looks at it, because the compiler doesn't look if it's
wrapped in an (EVAL-WHEN (EVAL) ...). This implies that there is some
secret situation that has been left out of the list.
I don't think this is EVAL-WHEN. EVAL-WHEN controls when the normal processing
would happen. What you are asking for, and I think this is reasonable, is
a way to control what processing happens, rather than when it happens.
A new feature to do this could be wedged into EVAL-WHEN, since obviously
EVAL-WHEN was designed to be extensible, but I'm not sure that's the place
to put it that makes the most sense.
In summary, I see three issues here:
(1) The name of EVAL-WHEN leads to confusion since this special form is
not actually related to the EVAL function. Should this problem be attacked
by changing the name or by documenting it better?
(2) The specification needs to clarify in which positions EVAL-WHEN is
allowed, in which positions it is forbidden, and in which positions it
is up to the implementation. This relates to the issue about the
positions in which DEFUN is allowed.
(3) It would be useful to have a way to turn off the compiler's normal
processing of a form. Some discussion of exactly what this means may be
in order.
∂03-Apr-86 1814 Bobrow.pa@Xerox.COM Re: EVAL-WHEN
Received: from XEROX.COM by SU-AI.ARPA with TCP; 3 Apr 86 18:14:20 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 03 APR 86 18:12:05 PST
Date: 3 Apr 86 18:12 PST
From: Bobrow.pa@Xerox.COM
Subject: Re: EVAL-WHEN
In-reply-to: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>'s message of
Thu, 3 Apr 86 18:23 -EST
To: Moon@SCRC-STONY-BROOK.ARPA
cc: Common-Lisp@SU-AI.ARPA
Message-ID: <860403-181205-2031@Xerox>
In fact I know of no way that is guaranteed to produce an
interpreted definition. Perhaps this is good, since I believe
there are some implementations that don't have an
interpreter, but simply compile everything.
Doesn't
(setf (symbol-function 'foo) (COPY '(LAMBDA ...)))
guarantee to produce a function definition not compiled by compiling the
file. If (setf (symbol-function 'foo) ...) compiles, then all bets are
off.
∂03-Apr-86 1953 BROOKS%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU Re: EVAL-WHEN
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 3 Apr 86 19:50:28 PST
Date: Thu 3 Apr 86 22:52:12-EST
From: "Rodney A. Brooks" <BROOKS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Subject: Re: EVAL-WHEN
To: Bobrow.pa@XEROX.COM
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <860403-181205-2031@Xerox>
Message-ID: <12196029728.56.BROOKS@OZ.AI.MIT.EDU>
Doesn't
(setf (symbol-function 'foo) (COPY '(LAMBDA ...)))
guarantee to produce a function definition not compiled by compiling the
file. If (setf (symbol-function 'foo) ...) compiles, then all bets are
off.
There is no requirement in CLtL that it be legal for a symbol function
cell to contain a lambda expression. In some implementations this
will cause an error when such a symbol is used in the function
position of an eval-ed expression. These implementations place a closure
in symbol function cells for interpreted functions, which all point
to the same compiled code sequence which takes a literal from the
closure (the literal is the lambda expression) and does the right
call into the middle of the interpreter.
-------
∂04-Apr-86 0605 greek%bach.decnet@hudson.dec.com Dave Moon's summary of EVAL-WHEN issues.
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 4 Apr 86 06:00:16 PST
Date: 4 Apr 86 08:48:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: Dave Moon's summary of EVAL-WHEN issues.
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Thank you. This summarizes the issues quite well. My suggestion that
there is another EVAL-WHEN situation was prompted by one simple desire.
There is no way to tell the compiler to digest a DEFMACRO for purposes
of future expansion, but not to evaluate it or dump it in the fastload
file. What I want is:
(EVAL-WHEN (COMPILER-DIGEST)
(DEFMACRO ...
I don't want to say (EVAL-WHEN (COMPILE) ...) because I don't want
to change my global environment. I don't want to say (EVAL-WHEN (LOAD) ...)
because I don't want it dumped.
I certainly agree that "EVAL-WHEN" is a real misnomer for this sort
of capability.
- Paul
------
∂04-Apr-86 0635 NGALL@G.BBN.COM Re: EVAL-WHEN
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 4 Apr 86 06:35:44 PST
Date: 4 Apr 1986 09:35-EST
Sender: NGALL@G.BBN.COM
Subject: Re: EVAL-WHEN
From: NGALL@G.BBN.COM
To: BROOKS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
Cc: Bobrow.pa@XEROX.COM, common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM] 4-Apr-86 09:35:03.NGALL>
In-Reply-To: <12196029728.56.BROOKS@OZ.AI.MIT.EDU>
Date: Thu 3 Apr 86 22:52:12-EST
From: "Rodney A. Brooks" <BROOKS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
To: Bobrow.pa@XEROX.COM
Subject: Re: EVAL-WHEN
In-Reply-To: <860403-181205-2031@Xerox>
Message-ID: <12196029728.56.BROOKS@OZ.AI.MIT.EDU>
Doesn't
(setf (symbol-function 'foo) (COPY '(LAMBDA ...)))
guarantee to produce a function definition not compiled by compiling the
file. If (setf (symbol-function 'foo) ...) compiles, then all bets are
off.
There is no requirement in CLtL that it be legal for a symbol function
cell to contain a lambda expression. In some implementations this
will cause an error when such a symbol is used in the function
position of an eval-ed expression. These implementations place a closure
in symbol function cells for interpreted functions, which all point
to the same compiled code sequence which takes a literal from the
closure (the literal is the lambda expression) and does the right
call into the middle of the interpreter.
-------
--------------------
This should definitely be pointed out on page 90. Also, exactly what objects
may be the value in a setf of (symbol-function <<symbol>>) should be clarified.
-- Nick
∂04-Apr-86 0741 DCP@ALLEGHENY.SCRC.Symbolics.COM Excuse me?
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 4 Apr 86 07:40:54 PST
Received: from FIREBIRD.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 11241; Fri 4-Apr-86 10:37:48-EST
Date: Fri, 4 Apr 86 10:37 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: Excuse me?
To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>,
common-lisp <common-lisp@SU-AI.ARPA>
In-Reply-To: The message of 3 Apr 86 15:08-EST from "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Message-ID: <860404103736.2.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: 3 Apr 86 15:08:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
You don't really mean that all of the lexical variables in a program
should be interned when the fastload file is loaded. Do you?
Excuse me, lexical variables aren't interned, symbols are. Maybe you
are asking if there is any direct correlation between the lexical
variable and the symbol it was named in the program. No, there is no
direct correlation in the Symbolics implementation. There is an
indirect association for debugging purposes, but execution of compiled
code never looks there.
∂04-Apr-86 0741 DCP@ALLEGHENY.SCRC.Symbolics.COM Excuse me?
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 4 Apr 86 07:41:17 PST
Received: from FIREBIRD.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 11242; Fri 4-Apr-86 10:38:03-EST
Date: Fri, 4 Apr 86 10:37 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: Excuse me?
To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>,
common-lisp <common-lisp@SU-AI.ARPA>
In-Reply-To: The message of 3 Apr 86 15:08-EST from "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Supersedes: <860404103736.2.DCP@FIREBIRD.SCRC.Symbolics.COM>
Message-ID: <860404103752.3.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: 3 Apr 86 15:08:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
You don't really mean that all of the lexical variables in a program
should be interned when the fastload file is loaded. Do you?
Excuse me, lexical variables aren't interned, print names are. Maybe
you are asking if there is any direct correlation between the lexical
variable and the symbol it was named in the program. No, there is no
direct correlation in the Symbolics implementation. There is an
indirect association for debugging purposes, but execution of compiled
code never looks there.
∂04-Apr-86 0802 gls@THINK-AQUINAS.ARPA EVAL-WHEN
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 4 Apr 86 07:46:53 PST
Received: from katherine by GODOT.THINK.COM via CHAOS; Fri, 4 Apr 86 10:47:30 est
Date: Fri, 4 Apr 86 10:49 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: EVAL-WHEN
To: Moon@SCRC-STONY-BROOK.ARPA, Common-Lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <860403182353.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <860404104902.1.GLS@THINK-KATHERINE.ARPA>
Date: Thu, 3 Apr 86 18:23 -EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Date: 1 Apr 86 09:14:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Mr. Fry has begun our bimonthly discussion of EVAL-WHEN (on April 1,
no less)....
I agree with you. EVAL-WHEN is intended to control when the normal processing
of its body is done and is not intended to imply that that processing is done
by the function EVAL. The choice of name is perhaps poor.
But DO-WHEN, the obvious alternative, is even worse. We really don't
have very good terminology for discussing these issues. A related
issue, that has been brought up before, is that sometimes it is useful
for a macro to be able to determine the expansion context (top-level,
interior form, compiled, interpreted, etc.).
--Guy
∂04-Apr-86 0802 gls@THINK-AQUINAS.ARPA Re: EVAL-WHEN
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 4 Apr 86 07:55:13 PST
Received: from katherine by GODOT.THINK.COM via CHAOS; Fri, 4 Apr 86 10:55:52 est
Date: Fri, 4 Apr 86 10:57 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Re: EVAL-WHEN
To: NGALL@G.BBN.COM, BROOKS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
Cc: Bobrow.pa@XEROX.COM, common-lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA
In-Reply-To: <[G.BBN.COM] 4-Apr-86 09:35:03.NGALL>
Message-Id: <860404105729.2.GLS@THINK-KATHERINE.ARPA>
Date: 4 Apr 1986 09:35-EST
From: NGALL@G.BBN.COM
Date: Thu 3 Apr 86 22:52:12-EST
From: "Rodney A. Brooks" <BROOKS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Doesn't
(setf (symbol-function 'foo) (COPY '(LAMBDA ...)))
guarantee to produce a function definition not compiled by compiling the
file. If (setf (symbol-function 'foo) ...) compiles, then all bets are
off.
There is no requirement in CLtL that it be legal for a symbol function
cell to contain a lambda expression. In some implementations this
will cause an error when such a symbol is used in the function
position of an eval-ed expression. These implementations place a closure
in symbol function cells for interpreted functions, which all point
to the same compiled code sequence which takes a literal from the
closure (the literal is the lambda expression) and does the right
call into the middle of the interpreter.
This should definitely be pointed out on page 90. Also, exactly what objects
may be the value in a setf of (symbol-function <<symbol>>) should be clarified.
I would contend that any Lisp object may be the value in a setf of
(symbol-function <symbol>), and that a subsequent invocation of
(symbol-function <symbol>) should retrieve exactly that object (or one
EQL to it). However, this does not prevent implementations from
wrapping that object in a closure internally on storing and unwrapping
it again on fetching.
--Guy
∂04-Apr-86 1102 Bobrow.pa@Xerox.COM Re: Dave Moon's summary of EVAL-WHEN issues.
Received: from XEROX.COM by SU-AI.ARPA with TCP; 4 Apr 86 11:02:02 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 04 APR 86 11:02:58 PST
Date: 4 Apr 86 10:37 PST
From: Bobrow.pa@Xerox.COM
Subject: Re: Dave Moon's summary of EVAL-WHEN issues.
In-reply-to: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>'s message
of 4 Apr 86 08:48:00 EST
To: common-lisp@su-ai.ARPA
cc: Bobrow.pa@Xerox.COM
Message-ID: <860404-110258-2543@Xerox>
If EVAL-WHEN and DO-WHEN have the wrong connotation,
how about USE-WHEN as less specific.
∂04-Apr-86 1256 jpg@ALLEGHENY.SCRC.Symbolics.COM EVAL-WHEN
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 4 Apr 86 12:48:44 PST
Received: from AUK.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 11302; Fri 4-Apr-86 15:49:20-EST
Date: Fri, 4 Apr 86 15:48 EST
From: Jeffrey P. Golden <jpg@ALLEGHENY.SCRC.Symbolics.COM>
Subject: EVAL-WHEN
To: gls@THINK-AQUINAS.ARPA
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <860404104902.1.GLS@THINK-KATHERINE.ARPA>
Message-ID: <860404154845.4.JPG@AUK.SCRC.Symbolics.COM>
Date: Fri, 4 Apr 86 10:49 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Date: Thu, 3 Apr 86 18:23 -EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Date: 1 Apr 86 09:14:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Mr. Fry has begun our bimonthly discussion of EVAL-WHEN (on April 1,
no less)....
I agree with you. EVAL-WHEN is intended to control when the normal processing
of its body is done and is not intended to imply that that processing is done
by the function EVAL. The choice of name is perhaps poor.
But DO-WHEN, the obvious alternative, is even worse.
Moon's English suggests PROCESS-WHEN .
∂04-Apr-86 1439 Pavel.pa@Xerox.COM Re: EVAL-WHEN
Received: from XEROX.COM by SU-AI.ARPA with TCP; 4 Apr 86 14:38:37 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 04 APR 86 14:37:08 PST
Date: Fri, 4 Apr 86 14:37:03 PST
From: Pavel.pa@Xerox.COM
Subject: Re: EVAL-WHEN
In-reply-to: <860404154845.4.JPG@AUK.SCRC.Symbolics.COM>
To: Common-Lisp@SU-AI.ARPA
Message-ID: <860404-143708-2836@Xerox>
> Moon's English suggests PROCESS-WHEN .
Please don't use any names with the word ``process''; eventually there
will be a multiprocessing proposal and it would be a pity to have
certain associations made.
Pavel
∂04-Apr-86 1452 WHOLEY@C.CS.CMU.EDU EVAL-WHEN
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 4 Apr 86 14:52:39 PST
Received: ID <WHOLEY@C.CS.CMU.EDU>; Fri 4 Apr 86 17:53:15-EST
Date: Fri, 4 Apr 1986 17:53 EST
Message-ID: <WHOLEY.12196237432.BABYL@C.CS.CMU.EDU>
Sender: WHOLEY@C.CS.CMU.EDU
From: Skef Wholey <Wholey@C.CS.CMU.EDU>
To: Pavel.pa@XEROX.COM
Cc: Common-Lisp@SU-AI.ARPA
Subject: EVAL-WHEN
In-reply-to: Msg of 4 Apr 1986 17:37-EST from Pavel.pa at Xerox.COM
Gosh, how about reviving a Lisp-tradition of using nomenclature specific to
computers and architectures -- the same that gave us CAR and CDR.
Looking at the PDP-10 instruction set, upon which the venerable MacLisp and
Interlisp spent most of their lives, we might arrive at XCT-WHEN. Spelling it
as normal people might, how about EXECUTE-WHEN?
--Skef
∂05-Apr-86 0745 hpfclp!diamant@hplabs.ARPA Re: EVAL-WHEN (really symbol-function)
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 5 Apr 86 07:45:43 PST
Received: by hplabs.ARPA ; Sat, 5 Apr 86 07:44:35 pst
Date: Sat, 5 Apr 86 07:44:35 pst
From: hpfclp!diamant@hplabs.ARPA
To: common-lisp@su-ai.ARPA
Subject: Re: EVAL-WHEN (really symbol-function)
Cc: diamant@hplabs.ARPA
From: Guy Steele <hplabs!gls@THINK-AQUINAS.ARPA>
Date: 4 Apr 1986 09:35-EST
From: NGALL@G.BBN.COM
Date: Thu 3 Apr 86 22:52:12-EST
From: "Rodney A. Brooks" <BROOKS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
There is no requirement in CLtL that it be legal for a symbol function
cell to contain a lambda expression. In some implementations this
will cause an error when such a symbol is used in the function
position of an eval-ed expression. These implementations place a closure
in symbol function cells for interpreted functions, which all point
to the same compiled code sequence which takes a literal from the
closure (the literal is the lambda expression) and does the right
call into the middle of the interpreter.
I agree.
This should definitely be pointed out on page 90. Also, exactly what
objects may be the value in a setf of (symbol-function <<symbol>>)
should be clarified.
Apparently, this too is true (considering that all of us do not seem to agree
on this).
I would contend that any Lisp object may be the value in a setf of
(symbol-function <symbol>), and that a subsequent invocation of
(symbol-function <symbol>) should retrieve exactly that object (or one
EQL to it). However, this does not prevent implementations from
wrapping that object in a closure internally on storing and unwrapping
it again on fetching.
--Guy
I have to disagree with you, Guy, for the following reason. The following
piece of code is perfectly legal Common Lisp:
(defun evaluate-fun (func &rest args)
(if (or (null (symbol-function func))
(macro-function func)
(special-form-p func))
(error "Not a function.")
(apply (symbol-function func) args))) ; I know that the symbol-function
; is redundant here -- that isn't
; the point
(evaluate-fun 'cons 'a 'b) ; should return (A . B)
Here is what CLtL says (p. 90):
"symbol-function returns the current global function definition named by
symbol. An error is signalled if the symbol has no function definition;
see fboundp. Note that the definition may be an object representing a
special form or macro. In the latter case, it is an error to attempt to
invoke the object as a function."
Note that the only valid object which may be returned is something of type
function (if the symbol has a global function definition). This is obvious
from the last sentence in the paragraph above. Since you claim
any object can be stored and that the retrieved value must be EQL, then any
object can be retrieved. This is totally contradictory to the quoted
paragraph above. It very explicitly states in which cases it is an error to
invoke the object as a function, and the case you are establishing is not
covered.
As far as allowing a lambda as the function cell, CLtL states that an
implementation is at liberty to always compile its code. If the lambda must
be left in its original state, then the implementation has to compile every
time a function is called, rather than when one is defined!
John Diamant
Systems Software Operation UUCP: {ihnp4!hpfcla,hplabs}!hpfclp!diamant
Hewlett Packard Co. ARPA/CSNET: diamant%hpfclp@hplabs
Fort Collins, CO
∂05-Apr-86 1223 preece%ccvaxa@gswd-vms Re: EVAL-WHEN (really symbol-functio
Received: from GSWD-VMS.ARPA by SU-AI.ARPA with TCP; 5 Apr 86 12:23:38 PST
Received: from ccvaxa.GSD (ccvaxa.ARPA) by gswd-vms.ARPA (5.9/)
id AA04856; Sat, 5 Apr 86 14:23:16 CST
Message-Id: <8604052023.AA04856@gswd-vms.ARPA>
Date: Sat, 5 Apr 86 14:21:38 cst
From: preece%ccvaxa@gswd-vms (Scott E. Preece)
To: COMMON-LISP@su-ai.arpa
Subject: Re: EVAL-WHEN (really symbol-functio
> From: hpfclp!diamant@hplabs.ARPA
> Subject: Re: EVAL-WHEN (really symbol-function)
>
> Here is what CLtL says (p. 90):
>
> "symbol-function returns the current global function definition named
> by symbol. An error is signalled if the symbol has no function
> definition; see fboundp. Note that the definition may be an object
> representing a special form or macro. In the latter case, it is an
> error to attempt to invoke the object as a function."
>
> Note that the only valid object which may be returned is something of
> type function (if the symbol has a global function definition). This
> is obvious from the last sentence in the paragraph above. Since you
> claim any object can be stored and that the retrieved value must be
> EQL, then any object can be retrieved. This is totally contradictory
> to the quoted paragraph above. It very explicitly states in which
> cases it is an error to invoke the object as a function, and the case
> you are establishing is not covered.
----------
I don't see any reason to read into the quoted text that those are the
ONLY cases that may not be invokable. I read that last sentence as a
cautionary example indicating that not everything residing in that slot
will be executable. I agree with Guy that the nature of things put
into that slot is implementation specific -- portable code should not
assume anything about it.
--
scott preece
gould/csd - urbana
ihnp4!uiucdcs!ccvaxa!preece
∂05-Apr-86 1425 Bobrow.pa@Xerox.COM Re: Symbol-function
Received: from XEROX.COM by SU-AI.ARPA with TCP; 5 Apr 86 14:25:15 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 05 APR 86 14:26:06 PST
Date: 5 Apr 86 14:26 PST
From: Bobrow.pa@Xerox.COM
Subject: Re: Symbol-function
To: COMMON-LISP@su-ai.arpa
Message-ID: <860405-142606-3435@Xerox>
I would contend that any Lisp object may be the value in a setf of
(symbol-function <symbol>), and that a subsequent invocation of
(symbol-function <symbol>) should retrieve exactly that object (or one
EQL to it). However, this does not prevent implementations from
wrapping that object in a closure internally on storing and unwrapping
it again on fetching.
--Guy
This seems right to me. What is not stated in CTtL is whether
an implementation has the right to check what is being put in
there and cause an error at storage time.
As far as allowing a lambda as the function cell, CLtL states that an
implementation is at liberty to always compile its code. If the lambda must
be left in its original state, then the implementation has to compile every
time a function is called, rather than when one is defined!
John Diamant
The hidden wrapping mentioned earlier (or an implicit wrapping through
a hash link from the expression) both allow first time compilation rather
than every time.
∂05-Apr-86 1513 DLW@SCRC-STONY-BROOK.ARPA Re: EVAL-WHEN (really symbol-function)
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 5 Apr 86 15:13:34 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 456333; Sat 5-Apr-86 18:13:28-EST
Date: Sat, 5 Apr 86 18:12 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Re: EVAL-WHEN (really symbol-function)
To: hpfclp!diamant%hplabs@MIT-MC.ARPA, common-lisp@SU-AI.ARPA
cc: diamant%hplabs@MIT-MC.ARPA
In-Reply-To: The message of 5 Apr 86 10:44-EST from hpfclp!diamant@hplabs.ARPA
Message-ID: <860405181258.4.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Sat, 5 Apr 86 07:44:35 pst
From: hpfclp!diamant@hplabs.ARPA
"symbol-function returns the current global function definition named by
symbol. An error is signalled if the symbol has no function definition;
see fboundp. Note that the definition may be an object representing a
special form or macro. In the latter case, it is an error to attempt to
invoke the object as a function."
Note that the only valid object which may be returned is something of type
function (if the symbol has a global function definition). This is obvious
from the last sentence in the paragraph above. Since you claim
any object can be stored and that the retrieved value must be EQL, then any
object can be retrieved. This is totally contradictory to the quoted
paragraph above. It very explicitly states in which cases it is an error to
invoke the object as a function, and the case you are establishing is not
covered.
Yes, it says that if the object is not a function, it is an error to
attempt to invoke it. However, it doesn't say anywhere that if the
object is not a function, it is an error to call symbol-function. So
there is no contradiction.
What you say is "obvious" is not obvious at all, because of the fuzzy
use of the word "valid".
∂05-Apr-86 1651 HENRIK@MC.LCS.MIT.EDU common-lisp on vaxes under vms?
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 5 Apr 86 16:51:09 PST
Date: Sat, 5 Apr 86 19:53:14 EST
From: "Lawrence A. DeLuca, Jr." <HENRIK@MC.LCS.MIT.EDU>
Subject: common-lisp on vaxes under vms?
To: Neches@ISI-VAXA.ARPA
cc: common-lisp@SU-AI.ARPA
In-reply-to: Msg of 31 Mar 1986 1134-PST () from Neches at ISI-VAXA.ARPA
Message-ID: <[MC.LCS.MIT.EDU].875107.860405.HENRIK>
He should look into NIL, MIT Common Lisp.
The contact person is Glenn Burke, GSB@MC.
I believe the cost of a distribution tape is about $100 these days,
but don't quote me on it.
larry...
∂05-Apr-86 2308 hpfclp!diamant@hplabs.ARPA Re: Symbol-function
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 5 Apr 86 23:07:54 PST
Received: by hplabs.ARPA ; Sat, 5 Apr 86 23:06:25 pst
Date: Sat, 5 Apr 86 23:06:25 pst
From: hpfclp!diamant@hplabs.ARPA
To: common-lisp@su-ai.ARPA
Subject: Re: Symbol-function
From: hplabs!preece%ccvaxa@gswd-vms (Scott E. Preece)
I don't see any reason to read into the quoted text that those are the
ONLY cases that may not be invokable. I read that last sentence as a
You may be correct about the intended meaning of the last sentence.
However, it would have been clearer to explicitly state that it is
an error to invoke any value returned by symbol-function for any symbol
which is not a function (I really mean a function here -- not that it has
a global function definition), and in addition point out that special forms
and macros fall in this category. In addition, if values are allowed for
symbol-function which aren't functions (or macros or special forms), that
should be stated explicitly. I don't agree with this rewording, however,
because I don't believe that implementations should be required to allow
anything other than a valid function to be setf'd by the user, and the
requirement on the return value should only be that it is logically equivalent
to what was passed in (that it will do "the right thing"). I already stated
the reasons in my previous message (performance and usability of
symbol-function).
By the way, I just noticed that I dropped a vital part of the sentence
in question when I quoted it. Look at the quote in my response below.
cautionary example indicating that not everything residing in that slot
will be executable. I agree with Guy that the nature of things put
into that slot is implementation specific -- portable code should not
assume anything about it.
I have quoted Guy's comment below, and I don't see how what he said indicates
that portable code can't count on what is in symbol-function. I think he
is saying that symbol-function is required to act in a portable manner and
that the implementation can have other (non-portable) mechanisms to get to
the non-EQL values it uses internally. I agree with your statement above;
I just don't think that is what Guy said!
From: Guy Steele <hplabs!gls@THINK-AQUINAS.ARPA>
I would contend that any Lisp object may be the value in a setf of
(symbol-function <symbol>), and that a subsequent invocation of
(symbol-function <symbol>) should retrieve exactly that object (or one
EQL to it). However, this does not prevent implementations from
wrapping that object in a closure internally on storing and unwrapping
it again on fetching.
From: Daniel L. Weinreb <hplabs!DLW@SCRC-QUABBIN.ARPA>
Yes, it says that if the object is not a function, it is an error to
attempt to invoke it. However, it doesn't say anywhere that if the
It doesn't say that if the object is not a function, it is an error -- it says
that if it is a macro or special form, it is an error. In particular, it
says that "the definition may be a function or may be an object representing
a special form or macro." In other words, it may be one of three things.
It may NOT be a random object. If I say "I may be at home or at work,"
it is correct to assume that I will not be at the beach (assuming I don't
live or work at the beach :-)).
object is not a function, it is an error to call symbol-function. So
there is no contradiction.
See above. I still say there is a contradiction.
What you say is "obvious" is not obvious at all, because of the fuzzy
use of the word "valid".
The use of the word valid was mine, not from CLtL, so it isn't the root of
the problem. I think we can all agree that the wording of symbol-function
is unclear, but I am more concerned about changing it so that the requirement
Guy mentioned is NOT made.
From: hplabs!Bobrow.pa@Xerox.COM
The hidden wrapping mentioned earlier (or an implicit wrapping through
a hash link from the expression) both allow first time compilation rather
than every time.
My comment regarding that was somewhat unclear. It is true that the
wrapping method does allow an implementation to compile or preprocess in
advance, but it means that the user doesn't really get the symbol-function
when he asks for it. It means either that
(apply (symbol-function 'foo)) and (apply 'foo) are different, or that
(apply (copy-list (symbol-function 'foo))) and (apply (symbol-function 'foo))
are different (in the case of a lambda). There is also a matter of
performance to consider. Making every function call require an extra hash
lookup (or a test to decide whether to do a hash lookup) is expensive and
doesn't really gain anything for you. What you are doing is making
the function cell just another value cell. It isn't. It is for executable
functions. Symbol-function ought to return the function cell and the
function cell ought to contain what the implementation really uses to execute
the function. Also, it should be an error to setf the function cell to
anything which is not of type function. That would, in fact, eliminate
the problem except for lambdas.
John Diamant
Systems Software Operation UUCP: {ihnp4!hpfcla,hplabs}!hpfclp!diamant
Hewlett Packard Co. ARPA/CSNET: diamant%hpfclp@hplabs
Fort Collins, CO
∂06-Apr-86 2101 RAM@C.CS.CMU.EDU EVAL-WHEN
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 6 Apr 86 21:01:40 PST
Received: ID <RAM@C.CS.CMU.EDU>; Mon 7 Apr 86 00:02:14-EST
Date: Mon, 7 Apr 1986 00:02 EST
Message-ID: <RAM.12196828898.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Subject: EVAL-WHEN
In-reply-to: Msg of Thu 3 Apr 86 18:23 -EST from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
Date: Thu, 3 Apr 86 18:23 -EST
From: David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
To: Common-Lisp at SU-AI.ARPA
Re: EVAL-WHEN
A couple of other questions have been asked before and never really
answered. Are EVAL-WHENs allowed down in the guts of a function or
macro and what do they mean there?
The discussion on page 66 that everybody hates was intended to rule out
EVAL-WHEN inside the guts of a function or a macro. I cannot think of
a meaningful interpretation of EVAL-WHEN in this position.
We may have to come up with a meaningful definition for non-top-level
EVAL-WHEN's. The reason is that the notion of a top-level form is
fairly worthless once you allow definitions inside of LET's.
Forbidding non-top-level EVAL-WHEN's would prohibit non-top-level use
of all user defining macros which expand into EVAL-WHEN's. This is
unacceptable since most hairy defining macros use EVAL-WHEN.
It is possible to meaningfully define non-top-level EVAL-WHEN's. The
LOAD and EVAL cases are easy: just compile or eval as PROGN (modulo
the situation interaction hair). The problem arises with the COMPILE
situation. The solution I suggest is to evaluate every EVAL-WHEN
COMPILE at compile time, no matter where it appears.
(1) The name of EVAL-WHEN leads to confusion since this special form is
not actually related to the EVAL function. Should this problem be attacked
by changing the name or by documenting it better?
EVAL-WHEN is far too obscure to be completely understood by anyone
who hasn't written it. Changing the name certainly won't help; better
documentation might.
(3) It would be useful to have a way to turn off the compiler's normal
processing of a form. Some discussion of exactly what this means may be
in order.
I agree. I thing most of the "normal processing" can be modeled as
implicit EVAL-WHEN COMPILE's. A possibility is to have a new
situation LOAD-ONLY which is like LOAD except that it inhibits
evaluation of all EVAL-WHEN COMPILE's (implicit or explicit) within
its lexical scope. Compilation of code within LOAD-ONLY should have no
effect on the compiler environment.
If we make some changes along these lines, we can totally eliminate
the notion of a top-level form from the language. I think this would
be a big improvement.
Rob
∂07-Apr-86 0619 greek%bach.decnet@hudson.dec.com Top-level EVAL-WHEN
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 7 Apr 86 06:19:16 PST
Date: 7 Apr 86 09:17:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: Top-level EVAL-WHEN
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
I didn't quite understand Rob's point, but no one is excluding EVAL-WHEN
buried in a top-level PROGN (as is typically generated by complex
macros). This is because all of the forms inside a top-level PROGN
are "promoted" to top-level forms.
- Paul
------
∂07-Apr-86 1246 gls@THINK-AQUINAS.ARPA Re: EVAL-WHEN (really symbol-function)
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 7 Apr 86 12:45:52 PST
Received: from guido by GODOT.THINK.COM via CHAOS; Mon, 7 Apr 86 15:44:40 est
Date: Mon, 7 Apr 86 15:46 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Re: EVAL-WHEN (really symbol-function)
To: hpfclp!diamant@HPLABS.ARPA, common-lisp@SU-AI.ARPA
Cc: diamant@HPLABS.ARPA, gls@THINK-AQUINAS.ARPA
In-Reply-To: <8604051547.AA06672@GODOT.THINK.COM>
Message-Id: <860407154604.4.GLS@GUIDO.THINK.COM>
Date: Sat, 5 Apr 86 07:44:35 pst
From: hpfclp!diamant@hplabs.ARPA
From: Guy Steele <hplabs!gls@THINK-AQUINAS.ARPA>
Date: 4 Apr 1986 09:35-EST
From: NGALL@G.BBN.COM
Date: Thu 3 Apr 86 22:52:12-EST
From: "Rodney A. Brooks" <BROOKS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
There is no requirement in CLtL that it be legal for a symbol function
cell to contain a lambda expression. ...
This should definitely be pointed out on page 90. Also, exactly what
objects may be the value in a setf of (symbol-function <<symbol>>)
should be clarified.
I would contend that any Lisp object may be the value in a setf of
(symbol-function <symbol>), and that a subsequent invocation of
(symbol-function <symbol>) should retrieve exactly that object (or one
EQL to it). However, this does not prevent implementations from
wrapping that object in a closure internally on storing and unwrapping
it again on fetching.
--Guy
I have to disagree with you, Guy, for the following reason. The following
piece of code is perfectly legal Common Lisp:
(defun evaluate-fun (func &rest args)
(if (or (null (symbol-function func))
(macro-function func)
(special-form-p func))
(error "Not a function.")
(apply (symbol-function func) args))) ; I know that the symbol-function
; is redundant here -- that isn't
; the point
(evaluate-fun 'cons 'a 'b) ; should return (A . B)
Note that (EVALUATE-FUN 'KDJSHFGDJSAHGFHJSADG) would signal an error
(assuming that KDJSHFGDJSAHGFHJSADG in in fact not FBOUNDP).
Here is what CLtL says (p. 90):
"symbol-function returns the current global function definition named by
symbol. An error is signalled if the symbol has no function definition;
see fboundp. Note that the definition may be an object representing a
special form or macro. In the latter case, it is an error to attempt to
invoke the object as a function."
Note that the only valid object which may be returned is something of type
function (if the symbol has a global function definition). This is obvious
from the last sentence in the paragraph above.
It may be obvious, but it is also wrong. I apologize for the misleading
terminology, but the term "function definition" is intended merely as a
label for a certain attribute of a symbol that conventionally has a
function as its value, but it is not meant to imply that that value is
necessarily of type FUNCTION. Indeed, CLtL does not (I believe) say
that a macro definition object is of type FUNCTION, and such objects are
certainly allowed to be the value of the function definition of a
symbol. Indeed, the fact that you have a NULL test in EVALUATE-FUN
above indicates that you expect NIL to be a possible result of
SYMBOL-FUNCTION, and NIL is not necessarily of type FUNCTION, is it?
Since you claim
any object can be stored and that the retrieved value must be EQL, then any
object can be retrieved. This is totally contradictory to the quoted
paragraph above. It very explicitly states in which cases it is an error to
invoke the object as a function, and the case you are establishing is not
covered.
"Having a function definition" merely means "is FBOUNDP"; it doesn't
mean "has an object of type FUNCTION as the function definition
attribute".
As far as allowing a lambda as the function cell, CLtL states that an
implementation is at liberty to always compile its code. If the lambda must
be left in its original state, then the implementation has to compile every
time a function is called, rather than when one is defined!
Non sequitur. It doesn't say that the code must be recompiled every
time. You can compile it once, and the system interpreter can use that
compiled code each time. It's just that the result of user-visible
calls to SYMBOL-FUNCTION should be the LAMBDA expression. (We might
want to change that, but that's how I read it now.)
John Diamant
Systems Software Operation UUCP: {ihnp4!hpfcla,hplabs}!hpfclp!diamant
Hewlett Packard Co. ARPA/CSNET: diamant%hpfclp@hplabs
Fort Collins, CO
--Guy
∂07-Apr-86 1531 Pavel.pa@Xerox.COM What can I redefine?
Received: from XEROX.COM by SU-AI.ARPA with TCP; 7 Apr 86 15:31:15 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 07 APR 86 15:15:44 PST
Date: Mon, 7 Apr 86 15:15:37 PST
From: Pavel.pa@Xerox.COM
Subject: What can I redefine?
To: Common-Lisp@SU-AI.ARPA
Message-ID: <860407-151544-1636@Xerox>
Consider the following code:
(defun bar (y) (* y 2))
(defun foo (x) (+ (bar x) 1))
(compile 'foo)
(defun bar (y) (* y 3))
(foo 7)
I think (hope) that everyone would agree that the final function call
returns 22. That is, it is expected that the compiler will not make use
of the current definition of ``bar'' in generating code for ``foo''.
But what about this case:
(defun foo (x) (+ (car x) 1))
(compile 'foo)
(defun car (y) (* y 3))
(foo 7)
Surely every compiler in the world will open-code ``car'' without asking
permission from the user. Thus this code should produce an error (or is
at least has undefined effect under the standard). Is this considered
``correct'' behavior for the compiler? Is its behavior expected to be
any different if the redefinition of ``car'' occurs before the
compilation? That is, is the compiler supposed to check for the
redefinition of constructs about which it has special knowledge?
Do any of these answers change if I replace ``car'' by ``disassemble''
in the above example? The idea is that one might be surprised to find a
compiler with special knowledge of the ``disassemble'' function and so
perhaps one should be allowed to count on calls to it not being
``compiled away''.
The silver book is, so far as I've seen, fairly silent on the issue of
what things the user is allowed to redefine. The only reference I've
found is this, from page 67:
``It is an error to attempt to redefine the name of a special form.''
I would like to see a statement in the standard that
``It is an error to attempt to redefine the name of any
function, macro, or special form defined in this standard.''
Otherwise, I'll feel like I'm cheating if I use any special knowledge in
my compiler without first checking somehow to be sure that no
redefinition has taken place.
Pavel
∂07-Apr-86 1540 RAM@C.CS.CMU.EDU Top-level EVAL-WHEN
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 7 Apr 86 15:40:14 PST
Received: ID <RAM@C.CS.CMU.EDU>; Mon 7 Apr 86 18:40:19-EST
Date: Mon, 7 Apr 1986 18:40 EST
Message-ID: <RAM.12197032427.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: "BACH::GREEK" <greek%bach.decnet@HUDSON.DEC.COM>
Cc: common-lisp <common-lisp@SU-AI.ARPA>
Subject: Top-level EVAL-WHEN
In-reply-to: Msg of 7 Apr 1986 09:17-EST from BACH::GREEK <greek%bach.decnet at hudson.dec.com>
Date: Monday, 7 April 1986 09:17-EST
From: BACH::GREEK <greek%bach.decnet at hudson.dec.com>
Reply-To: BACH::GREEK <greek%bach.decnet at hudson.dec.com>
To: common-lisp <common-lisp at su-ai.ARPA>
Re: Top-level EVAL-WHEN
I didn't quite understand Rob's point, but no one is excluding EVAL-WHEN
buried in a top-level PROGN (as is typically generated by complex
macros). This is because all of the forms inside a top-level PROGN
are "promoted" to top-level forms.
If I define a macro DEF-FROB which has some code in its body, I want to
be able to use this defining macro within a let:
(let ((foo ...))
(def-frob my-frob (x) ...))
If non-top-level EVAL-WHEN's are prohibited, then users cannot define
defining macros which expand into code containing EVAL-WHEN's unless
those macros are only used at top level. I don't think that anyone
considers the body of a let to be at top level; if they do, then where
does top-level stop? One way to look at my proposal is as saying
"everywhere is top-level." I see no need for defining the notion of
top-level, and see good reasons not to.
Rob
∂07-Apr-86 1643 RAM@C.CS.CMU.EDU What can I redefine?
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 7 Apr 86 16:43:15 PST
Received: ID <RAM@C.CS.CMU.EDU>; Mon 7 Apr 86 19:44:08-EST
Date: Mon, 7 Apr 1986 19:44 EST
Message-ID: <RAM.12197044053.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: Pavel.pa@XEROX.COM
Cc: Common-Lisp@SU-AI.ARPA
Subject: What can I redefine?
In-reply-to: Msg of 7 Apr 1986 18:15-EST from Pavel.pa at Xerox.COM
My interpretation of the consensus is that you can redefine
anything which isn't a special form. The compiler is free to compile
any standard function however it wants unless you make a NOTINLINE
declaration, which forces the compiler to make a normal function call.
This issue was brought up before, and there was fairly strong
opposition to prohibiting redefinition. Redefining standard functions
is part of the Lisp culture.
I would have no objection to saying that redefining standard
functions is an error. This is because no truly portable program can
redefine any standard function, since it cannot know what the rest of
the system expects of the implementation of that function. The usual
Lisp environment allows multiple applications to coexist in the same
Lisp; this cannot work if applications go around redefining things at
random.
Rob
∂08-Apr-86 0707 greek%bach.decnet@hudson.dec.com EVAL-WHEN buried inside a form.
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 8 Apr 86 07:06:41 PST
Date: 8 Apr 86 09:53:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: EVAL-WHEN buried inside a form.
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Well, I have to agree with Rob that it would be restrictive to disallow
EVAL-WHENs buried inside of arbitrary forms. Does the model for processing
EVAL-WHEN given in CLtL take into account that they might not be at
"top level"?
- Paul
------
∂08-Apr-86 0749 DCP@SCRC-STONY-BROOK.ARPA What can I redefine?
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 8 Apr 86 07:49:32 PST
Received: from FIREBIRD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 457920; Tue 8-Apr-86 10:43:27-EST
Date: Tue, 8 Apr 86 10:42 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: What can I redefine?
To: Rob MacLachlan <RAM%C.CS.CMU.EDU@SCRC-STONY-BROOK.ARPA>,
Pavel.pa%XEROX.COM@SCRC-STONY-BROOK.ARPA
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <RAM.12197044053.BABYL@C.CS.CMU.EDU>
References: <860407-151544-1636@Xerox>,
<RAM.12197044053.BABYL@C.CS.CMU.EDU>
Message-ID: <860408104204.5.DCP@FIREBIRD.SCRC.Symbolics.COM>
[Excuse the possibly bogus mail addresses; our domain system doesn't
deal with down domain servers very well.]
In addition, some systems know that CAR was not originally defined by
the user, and may complain if the user tries to redefine it. If the
user did say "Yes, it's OK." I wouldn't be at all surprised if the user
wouldn't immediately have to reload the Lisp system, as the system will
probably get very unhappy when CAR returns something other than the
first item of a list.
∂08-Apr-86 0947 greek%bach.decnet@hudson.dec.com EVAL-WHEN buried inside forms.
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 8 Apr 86 09:47:21 PST
Date: 8 Apr 86 12:43:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: EVAL-WHEN buried inside forms.
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Please keep in mind that this message assumes I understand how EVAL-WHEN
is supposed to work, which I might not.
I don't believe that the model for EVAL-WHEN takes into account uses at
other than "top level". For example:
(eval-when (compile load)
(let (...)
(eval-when (eval)
...stuff...)
...)
)
The LET will be EVALed at compile-time by virtue of the compile
situation in the outer EVAL-WHEN. Then, as the compiler begins to
process the body of the LET, it will see the inner EVAL-WHEN and EVAL
the stuff, then discard it. Oops, the stuff was EVALed twice!
In order to deal with EVAL-WHEN forms anywhere, we need to improve the
model. But it's not clear to me what some combinations mean.
- Paul
------
∂08-Apr-86 1434 NGALL@G.BBN.COM Re: EVAL-WHEN (really symbol-function)
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 8 Apr 86 14:33:47 PST
Date: 8 Apr 1986 17:34-EST
Sender: NGALL@G.BBN.COM
Subject: Re: EVAL-WHEN (really symbol-function)
From: NGALL@G.BBN.COM
To: gls@AQUINAS.THINK.COM
Cc: common-lisp@SU-AI.ARPA, diamant@HPLABS.ARPA
Message-ID: <[G.BBN.COM] 8-Apr-86 17:34:18.NGALL>
In-Reply-To: <860407154604.4.GLS@GUIDO.THINK.COM>
Date: Mon, 7 Apr 86 15:46 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
To: hpfclp!diamant@HPLABS.ARPA, common-lisp@SU-AI.ARPA
Subject: Re: EVAL-WHEN (really symbol-function)
In-Reply-To: <8604051547.AA06672@GODOT.THINK.COM>
Message-ID: <860407154604.4.GLS@GUIDO.THINK.COM>
Date: Sat, 5 Apr 86 07:44:35 pst
From: hpfclp!diamant@hplabs.ARPA
From: Guy Steele <hplabs!gls@THINK-AQUINAS.ARPA>
Date: 4 Apr 1986 09:35-EST
From: NGALL@G.BBN.COM
Date: Thu 3 Apr 86 22:52:12-EST
From: "Rodney A. Brooks" <BROOKS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
There is no requirement in CLtL that it be legal for a symbol function
cell to contain a lambda expression. ...
This should definitely be pointed out on page 90. Also, exactly what
objects may be the value in a setf of (symbol-function <<symbol>>)
should be clarified.
I would contend that any Lisp object may be the value in a setf of
(symbol-function <symbol>), and that a subsequent invocation of
(symbol-function <symbol>) should retrieve exactly that object (or one
EQL to it). However, this does not prevent implementations from
wrapping that object in a closure internally on storing and unwrapping
it again on fetching.
--Guy
...
It may be obvious, but it is also wrong. I apologize for the misleading
terminology, but the term "function definition" is intended merely as a
label for a certain attribute of a symbol that conventionally has a
function as its value, but it is not meant to imply that that value is
necessarily of type FUNCTION. Indeed, CLtL does not (I believe) say
that a macro definition object is of type FUNCTION, and such objects are
certainly allowed to be the value of the function definition of a
symbol. Indeed, the fact that you have a NULL test in EVALUATE-FUN
above indicates that you expect NIL to be a possible result of
SYMBOL-FUNCTION, and NIL is not necessarily of type FUNCTION, is it?
"Having a function definition" merely means "is FBOUNDP"; it doesn't
mean "has an object of type FUNCTION as the function definition
attribute".
--Guy
1. How many implementations interpreted CLtL the way Guy intended?
In other words, How many implementations allow, for example,
(setf (symbol-function 'foo) 1.0d0). VaxLisp does not allow this.
2. How many implementations interpreted CLtL as implying that only
objects that can be returned from the FUNCTION special form or
objects that are returned by calling SYMBOL-FUNCTION with a symbol
naming a special form or macro as its argument can legally be used as
the value in a SETF of SYMBOL-FUNCTION? VaxLisp seems to have
interpreted it this way.
I bet that most implemetnations are closer to interpretation 2 than to
1.
3. Under interp 1. consider the following:
(defun foo () (print "hello"))
(setf (symbol-function 'bar) 'foo)
Which of the following are legal?:
(funcall 'bar) ; A
(funcall #'bar) ; B
(funcall (symbol-function 'bar)) ; C
Case C is the only one I am sure is legal. The other two depend on
the ambiguous description of function calling (pg. 58) and APPLY (pg.
107).
I guess my point is that I think most implementors followed
interpretation 2 which prevents the kind of confusion where C is legal
but B is not; so we should clarify CLtL in that direction rather than
towards interp 1.
Whatever interp. is finally chosen, APPLY should be clarified so that
we known exactly what can be applied (and if a symbol is applied, what
exactly can be legally the function definition).
-- Nick
∂08-Apr-86 1505 NGALL@G.BBN.COM Extent of function definition created by FLET/LABELS
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 8 Apr 86 15:05:21 PST
Date: 8 Apr 1986 18:06-EST
Sender: NGALL@G.BBN.COM
Subject: Extent of function definition created by FLET/LABELS
From: NGALL@G.BBN.COM
To: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM] 8-Apr-86 18:06:32.NGALL>
Is the following legal CL:
(funcall (labels ((foo () (print "hello"))
(bar () (foo)))
#'bar))
If not, where is it forbidden?
-- Nick
P.S. It works in VaxLisp.
∂08-Apr-86 1754 DCP@SCRC-STONY-BROOK.ARPA Extent of function definition created by FLET/LABELS
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 8 Apr 86 17:54:15 PST
Received: from FIREBIRD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 458753; Tue 8-Apr-86 19:51:00-EST
Date: Tue, 8 Apr 86 19:49 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: Extent of function definition created by FLET/LABELS
To: NGALL%G.BBN.COM@SCRC-STONY-BROOK.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <[G.BBN.COM] 8-Apr-86 18:06:32.NGALL>
Message-ID: <860408194941.5.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: 8 Apr 1986 18:06-EST
From: NGALL@G.BBN.COM
Is the following legal CL:
(funcall (labels ((foo () (print "hello"))
(bar () (foo)))
#'bar))
If not, where is it forbidden?
-- Nick
P.S. It works in VaxLisp.
I'm very surprised CLtL does not say that the functions created by FLET
and LABELS have lexical scope (I think it does say that) and indefinite
extent (that's what it doesn't say). Page 37 does say "most Common Lisp
data objects have indefinite extent." I think you will find most
implementations will interpret FLET and LABELS to have indefinite
extent.
∂08-Apr-86 1846 RWK@SCRC-STONY-BROOK.ARPA Extent of function definition created by FLET/LABELS
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 8 Apr 86 18:45:51 PST
Received: from WHITE-BIRD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 458824; Tue 8-Apr-86 21:13:13-EST
Date: Tue, 8 Apr 86 21:09 EST
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
Subject: Extent of function definition created by FLET/LABELS
To: NGALL@G.BBN.COM
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <[G.BBN.COM] 8-Apr-86 18:06:32.NGALL>
Message-ID: <860408210903.8.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: 8 Apr 1986 18:06-EST
From: NGALL@G.BBN.COM
Is the following legal CL:
Yes, it is quite legal. We do this extensively in
our system code.
(funcall (labels ((foo () (print "hello"))
(bar () (foo)))
#'bar))
If not, where is it forbidden?
-- Nick
P.S. It works in VaxLisp.
∂08-Apr-86 1924 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Re: Symbol-function
Received: from CS.UCL.AC.UK by SU-AI.ARPA with TCP; 8 Apr 86 19:23:37 PST
Received: from aiva.edinburgh.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP
id a003080; 8 Apr 86 22:55 BST
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@cs.ucl.ac.uk>
Date: Tue, 8 Apr 86 18:28:29 GMT
Message-Id: <3032.8604081828@aiva.ed.ac.uk>
To: common-lisp@su-ai.arpa, diamant <@hplabs.arpa:diamant@hpfclp>
Subject: Re: Symbol-function
Can the value of SYMBOL-FUNCTION be anything or must it be a function? I
seem to recall someone mentioning in the discussion about why the function
value of a symbol was not just the variable value that the function value
could be guaranteed to be something you could just transfer through rather
than some random value that you had to check for function-ness. Of course,
you could wrap the random value in something that could be transferred
through, as is often done with non-compiled functions, so this doesn't
really resolve the issue.
- Jeff
∂08-Apr-86 2325 RAM@C.CS.CMU.EDU EVAL-WHEN buried inside forms.
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 8 Apr 86 23:25:24 PST
Received: ID <RAM@C.CS.CMU.EDU>; Wed 9 Apr 86 02:25:37-EST
Date: Wed, 9 Apr 1986 02:25 EST
Message-ID: <RAM.12197379288.BABYL@>
From: Rob MacLachlan <RAM@λλ>
To: "BACH::GREEK" <greek%bach.decnet@HUDSON.DEC.COM>
Cc: common-lisp <common-lisp@SU-AI.ARPA>
Subject: EVAL-WHEN buried inside forms.
In-reply-to: Msg of 8 Apr 1986 12:43-EST from BACH::GREEK <greek%bach.decnet at hudson.dec.com>
I agree that CLTL doesn't adequately specify the semantics of
non-top-level EVAL-WHEN's. This isn't surprising, since there
evidently wasn't any attempt to. Multiple compile-time evaluation is
a common characteristic of incorrect eval-when implementations, even
when they don't attempt to handle non-top-level occurrences.
In the Spice Lisp compiler, the Stuff in your example is only
evaluated once. When the compiler initially evaluates the outer
EVAL-WHEN, it binds a special indicating that the code within it has
already been evaluated. The compiler doesn't evaluate non-top-level
EVAL-WHEN's when this flag is true. The flag gets bound to NIL when
the compiler encounters a form which isn't wasn't evaled, such as an
EVAL-WHEN LOAD.
The compiler also needs to communicate with the interpreter so that
when the compiler evals a form, the interpreter evaluates EVAL-WHEN
COMPILE's which it would otherwise ignore.
Rob
∂09-Apr-86 0509 smh@mit-ems.ARPA Re: What can I redefine?
Received: from MIT-EMS.ARPA by SU-AI.ARPA with TCP; 9 Apr 86 05:09:37 PST
Received: by mit-ems.ARPA (4.12/4.8) id AA06539; Wed, 9 Apr 86 08:09:04 est
Date: Wed, 9 Apr 86 08:09:04 est
From: Steven Haflich <smh@mit-ems.ARPA>
Message-Id: <8604091309.AA06539@mit-ems.ARPA>
To: Common-Lisp@SU-AI
Subject: Re: What can I redefine?
> From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
>
> In addition, some systems know that CAR was not originally defined by
> the user, and may complain if the user tries to redefine it. If the
> user did say "Yes, it's OK." I wouldn't be at all surprised if the user
> wouldn't immediately have to reload the Lisp system, as the system will
> probably get very unhappy when CAR returns something other than the
> first item of a list.
A few months ago when I was about to reboot anyway I redefined CAR on a
3670. I played with the system for another ten minutes without finding
anything that this broke. Even Chaos and the GC still worked. This
isn't too surprising when you think about it.
All this was discussed several months ago. It would appear the
compiler is permitted to open code anything for which it can prove it
knows the execution environment definition. I can see no reason why
this should even exclude user-DEFUNed functions in the compilation
environment for COMPILE, or functions DEFUNed in the same file for
COMPILE-FILE.
Whatever one thinks about this mess, the issue probably should be
raised more explicitly in CLtL. Meanwhile, one can always write:
(FUNCALL (SYMBOL-FUNCTION 'CAR) FOO)
instead of
(CAR FOO)
and hope no one has redefined FUNCALL or SYMBOL-FUNCTION. Gag.
∂09-Apr-86 0754 Swenson.Multics@CISL-SERVICE-MULTICS.ARPA Common Loops
Received: from CISL-SERVICE-MULTICS.ARPA by SU-AI.ARPA with TCP; 9 Apr 86 07:54:18 PST
Date: Wed, 9 Apr 86 09:43 EST
From: "Eric J. Swenson" <Swenson@CISL-SERVICE-MULTICS.ARPA>
Subject: Common Loops
To: common-lisp@SU-AI.ARPA
Message-ID: <860409144332.683474@CISL-SERVICE-MULTICS.ARPA>
Are there any on-line documents on CommonLoops that are available to the
ARPA community via FTP?
∂09-Apr-86 0918 Swenson.Multics@CISL-SERVICE-MULTICS.ARPA Common Loops
Received: from CISL-SERVICE-MULTICS.ARPA by SU-AI.ARPA with TCP; 9 Apr 86 07:54:18 PST
Date: Wed, 9 Apr 86 09:43 EST
From: "Eric J. Swenson" <Swenson@CISL-SERVICE-MULTICS.ARPA>
Subject: Common Loops
To: common-lisp@SU-AI.ARPA
Message-ID: <860409144332.683474@CISL-SERVICE-MULTICS.ARPA>
Are there any on-line documents on CommonLoops that are available to the
ARPA community via FTP?
∂09-Apr-86 1921 FAHLMAN@C.CS.CMU.EDU Dave Moon's summary of EVAL-WHEN issues.
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 9 Apr 86 19:21:07 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 9 Apr 86 22:21:52-EST
Date: Wed, 9 Apr 1986 22:21 EST
Message-ID: <FAHLMAN.12197597061.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Dave Moon's summary of EVAL-WHEN issues.
In-reply-to: Msg of 4 Apr 1986 13:37-EST from Bobrow.pa at Xerox.COM
I think that instead of worrying about changing the name, we need to
completely replace the current Eval-When. We need to figure out what
kinds of control we need over when things are to be evaluated, compiled,
etc., and then we need good clean ways of expressing these directives in
portable code files. This is all tied in with top-level forms and
issues about what the compiler does to the compile-time and load-time
environments. Once we know what sorts of operations we want to
support, then we should worry about names. Assuming that these new
controls are not equivalent to the current Eval-When, we will want new
names for these things so that the cut-over fromt he old Eval-When can
occur gradually.
-- Scott
∂10-Apr-86 0004 cfry%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU Dave Moon's summary of EVAL-WHEN issues.
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 10 Apr 86 00:04:07 PST
Received: from RICKY.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 10 Apr 86 03:06-EST
Date: Thu, 10 Apr 86 03:05 EST
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
Subject: Dave Moon's summary of EVAL-WHEN issues.
To: Fahlman@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12197597061.BABYL@C.CS.CMU.EDU>
Message-ID: <860410030502.2.CFRY@RICKY.AI.MIT.EDU>
Received: from MC.LCS.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 9 Apr 86 22:47-EST
Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 9 Apr 86 22:46:46 EST
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 9 Apr 86 19:21:07 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 9 Apr 86 22:21:52-EST
Date: Wed, 9 Apr 1986 22:21 EST
Message-ID: <FAHLMAN.12197597061.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Dave Moon's summary of EVAL-WHEN issues.
In-reply-to: Msg of 4 Apr 1986 13:37-EST from Bobrow.pa at Xerox.COM
I think that instead of worrying about changing the name, we need to
completely replace the current Eval-When. We need to figure out what
kinds of control we need over when things are to be evaluated, compiled,
etc., and then we need good clean ways of expressing these directives in
portable code files. This is all tied in with top-level forms and
issues about what the compiler does to the compile-time and load-time
environments. Once we know what sorts of operations we want to
support, then we should worry about names. Assuming that these new
controls are not equivalent to the current Eval-When, we will want new
names for these things so that the cut-over fromt he old Eval-When can
occur gradually.
-- Scott
As the instigator of this round of eval-when-wars, I was horrified at the
volume of mail generated on the topic over the last couple of weeks.
Scott is EXACTLY right!
Perhaps a few coherent proposals could be passed
out and/or expalined at the upcomming meeting.
∂10-Apr-86 0051 RAM@C.CS.CMU.EDU Successor to eval-when?
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 10 Apr 86 00:50:38 PST
Received: ID <RAM@C.CS.CMU.EDU>; Thu 10 Apr 86 03:51:25-EST
Date: Thu, 10 Apr 1986 03:51 EST
Message-ID: <RAM.12197657052.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Successor to eval-when?
If anyone has an idea for a replacement to eval-when, speak up. I
don't have any idea of anything that would be better. There seem to
be two main reasons people are upset with eval-when:
1] It is currently ill-defined.
2] It is hard to understand.
I believe that the first problem is fairly easy to fix; I suspect that
the second problem is inherent in the nature of the beast.
Rob
∂10-Apr-86 0655 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Re: EVAL-WHEN (really symbol-function)
Received: from CS.UCL.AC.UK by SU-AI.ARPA with TCP; 10 Apr 86 06:52:46 PST
Received: from aiva.edinburgh.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP
id a001492; 10 Apr 86 8:18 BST
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@cs.ucl.ac.uk>
Date: Wed, 9 Apr 86 21:08:05 GMT
Message-Id: <12977.8604092108@aiva.ed.ac.uk>
To: NGALL@bbng.arpa, gls@aquinas.think.com
Subject: Re: EVAL-WHEN (really symbol-function)
Cc: common-lisp@su-ai.arpa, diamant@hplabs.arpa
Date: 8 Apr 1986 17:34-EST
From: NGALL@arpa.bbng
1. How many implementations interpreted CLtL the way Guy intended?
In other words, How many implementations allow, for example,
(setf (symbol-function 'foo) 1.0d0). VaxLisp does not allow this.
I tried (setf (symbol-function 'foo) 'bar) in the two CLs within easy
reach. Both signal errors, and not particularly nice ones either. (I'd
expect something like "illegal value ~S for SYMBOL-FUNCTION", but I get
things like "segmentation-violation".)
2...
3. Under interp 1. consider the following:
(defun foo () (print "hello"))
(setf (symbol-function 'bar) 'foo)
Which of the following are legal?:
(funcall 'bar) ; A
(funcall #'bar) ; B
(funcall (symbol-function 'bar)) ; C
Case C is the only one I am sure is legal. The other two depend on
the ambiguous description of function calling (pg. 58) and APPLY (pg.
107).
Case C should be legal because it should be the same as (funcall 'foo).
Case B should also be legal because #'bar == (function bar) should be
equivalent to (symbol-function 'bar) in a context where bar refers to a
global function (i.e., when there's no lexically enclosing flet or
labels that binds bar), as it does in this case.
Case A should be illegal, but CLtL does not explicitly exclude it.
Cases B and C dereference 'bar one level in the evaluation of the
argument form; here funcall would have to do both levels (from bar to
foo and from foo to #'foo) itself. Nothing says that apply and funcall
do repeated dereferencing in this case, but that would not be an
unreasonable interpretation of pages 32 (section 2.13) and 107. Take
page 107. If 'function' is a symbol, its global functional value is
"used". Presumably, it is used as a function, in which case it is
reasonable to suppose the global value might also be a symbol and that
the same rule would be applied again.
The reason I say that case A should be illegal is that Common Lisp does
not in general repeatedly dereference symbols used as functions in this
way. Some Lisps have done so, even if you just write (f x) instead of
using FUNCALL or APPLY, but typically only in the interpreter.
I guess my point is that I think most implementors followed
interpretation 2 which prevents the kind of confusion where C is legal
but B is not; so we should clarify CLtL in that direction rather than
towards interp 1.
I don't think there is a case where C should be legal and B not. Both
should be legal if arbitrary values are allowed to be SYMBOL-FUNCTIONs;
neither should be legal otherwise. (Except in those contexts where
(FUNCTION x) does not just do (SYMBOL-FUNCTION x) -- but that does not
depend on interp 1 vs interp 2.)
Whatever interp. is finally chosen, APPLY should be clarified so that
we known exactly what can be applied (and if a symbol is applied, what
exactly can be legally the function definition).
I agree that the definition of APPLY is deficient. For example, it
seems to list explicitly all the things that might be functions and yet
it never mentions closures. Compare this list to that on page 32.
In general, my favorite pages for answering questions concerning what
things are legal as functions are pages 32 (section 2.13) and 59
(section 5.2). Page 59 is, for example, the place where the distinction
between the use of lambda-expressions and symbols as *names* for
functions and their use as function objects is most clearly made.
-- Jeff
∂10-Apr-86 0706 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Re: Extent of function definition created by FLET/LABELS
Received: from CS.UCL.AC.UK by SU-AI.ARPA with TCP; 10 Apr 86 06:57:09 PST
Received: from aiva.edinburgh.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP
id a001807; 10 Apr 86 9:12 BST
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@cs.ucl.ac.uk>
Date: Wed, 9 Apr 86 20:07:59 GMT
Message-Id: <12612.8604092007@aiva.ed.ac.uk>
To: NGALL@bbng.arpa, common-lisp@su-ai.arpa
Subject: Re: Extent of function definition created by FLET/LABELS
Date: 8 Apr 1986 18:06-EST
From: NGALL@arpa.bbng
Is the following legal CL:
(funcall (labels ((foo () (print "hello"))
(bar () (foo)))
#'bar))
If not, where is it forbidden?
I'm somewhat puzzled by this question. I sounds as if you think there's a
pretty good chance that it isn't legal but a pretty poor chance that the Book
says so. I would say that it's almost certainly legal, although the book's
clarity on this point may still be in doubt.
I can't find anything in CLtL that explicitly says the functions created by
LABELS have indefinite extent, although it is reasonably clear that functions
made from lambda-expressions do (see, e.g., the COMPOSE example on page 37).
And named functions are explicitly connected to lambda-expressions in section
5.2.1 on page 59. That the FOO in the definition of BAR refers to the right
local function should also be clear from the definition of LABELS in page 113
and 5.2.1 again.
-- Jeff
∂10-Apr-86 0816 gls@THINK-AQUINAS.ARPA Extent of function definition created by FLET/LABELS
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 10 Apr 86 08:10:02 PST
Received: from thorlac by GODOT.THINK.COM via CHAOS; Thu, 10 Apr 86 11:10:47 est
Date: Thu, 10 Apr 86 11:12 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Extent of function definition created by FLET/LABELS
To: NGALL@G.BBN.COM, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <[G.BBN.COM] 8-Apr-86 18:06:32.NGALL>
Message-Id: <860410111224.2.GLS@THINK-THORLAC.ARPA>
Date: 8 Apr 1986 18:06-EST
From: NGALL@G.BBN.COM
Is the following legal CL:
(funcall (labels ((foo () (print "hello"))
(bar () (foo)))
#'bar))
If not, where is it forbidden?
-- Nick
P.S. It works in VaxLisp.
This is certainly legal. I am glad that it works in VaxLisp.
--Guy
∂10-Apr-86 0816 gls@THINK-AQUINAS.ARPA Extent of function definition created by FLET/LABELS: additional remark
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 10 Apr 86 08:13:12 PST
Received: from thorlac by GODOT.THINK.COM via CHAOS; Thu, 10 Apr 86 11:13:56 est
Date: Thu, 10 Apr 86 11:15 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Extent of function definition created by FLET/LABELS: additional remark
To: NGALL@G.BBN.COM, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <[G.BBN.COM] 8-Apr-86 18:06:32.NGALL>
Message-Id: <860410111533.3.GLS@THINK-THORLAC.ARPA>
Date: 8 Apr 1986 18:06-EST
From: NGALL@G.BBN.COM
Is the following legal CL:
(funcall (labels ((foo () (print "hello"))
(bar () (foo)))
#'bar))
If not, where is it forbidden?
-- Nick
P.S. It works in VaxLisp.
Page 39 ought to state that bindings of function names,
as well as variable bindings, have lexical scope and
indefinite extent. Page 113 also ought to make explicit
mention of this.
--Guy
∂10-Apr-86 0859 NGALL@G.BBN.COM Re: Extent of function definition created by FLET/LABELS: ad...
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 10 Apr 86 08:55:36 PST
Date: 10 Apr 1986 11:55-EST
Sender: NGALL@G.BBN.COM
Subject: Re: Extent of function definition created by FLET/LABELS: ad...
From: NGALL@G.BBN.COM
To: gls@AQUINAS.THINK.COM
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]10-Apr-86 11:55:49.NGALL>
In-Reply-To: <860410111533.3.GLS@THINK-THORLAC.ARPA>
Date: Thu, 10 Apr 86 11:15 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
To: NGALL@G.BBN.COM, common-lisp@SU-AI.ARPA
Subject: Extent of function definition created by FLET/LABELS: additional remark
In-Reply-To: <[G.BBN.COM] 8-Apr-86 18:06:32.NGALL>
Message-ID: <860410111533.3.GLS@THINK-THORLAC.ARPA>
Date: 8 Apr 1986 18:06-EST
From: NGALL@G.BBN.COM
Is the following legal CL:
(funcall (labels ((foo () (print "hello"))
(bar () (foo)))
#'bar))
If not, where is it forbidden?
-- Nick
P.S. It works in VaxLisp.
Page 39 ought to state that bindings of function names,
as well as variable bindings, have lexical scope and
indefinite extent. Page 113 also ought to make explicit
mention of this.
--Guy
My question really has nothing to do with the BINDING of a function
name, otherwise I would have asked if the following were legal:
(funcall (flet ((foo () (print "hello")))
#'(lambda () (foo))))
My question was really whether or not the actual function object
created by FLET/LABELS has indefinite extent, and I take it that it
is. The fact that it is should be mentioned in the appropriate
places.
-- Nick
∂10-Apr-86 1005 NGALL@G.BBN.COM Re: EVAL-WHEN (really symbol-function)
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 10 Apr 86 09:33:39 PST
Date: 10 Apr 1986 12:34-EST
Sender: NGALL@G.BBN.COM
Subject: Re: EVAL-WHEN (really symbol-function)
From: NGALL@G.BBN.COM
To: jeff%aiva.edinburgh.ac.uk@CS.UCL.AC.UK
Cc: gls@AQUINAS.THINK.COM, common-lisp@SU-AI.ARPA
Cc: diamant@HPLABS.ARPA
Message-ID: <[G.BBN.COM]10-Apr-86 12:34:53.NGALL>
In-Reply-To: <12977.8604092108@aiva.ed.ac.uk>
Date: Wed, 9 Apr 86 21:08:05 GMT
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@cs.ucl.ac.uk>
To: NGALL@bbng.arpa, gls@aquinas.think.com
Subject: Re: EVAL-WHEN (really symbol-function)
Message-ID: <12977.8604092108@aiva.ed.ac.uk>
Date: 8 Apr 1986 17:34-EST
From: NGALL@arpa.bbng
1. How many implementations interpreted CLtL the way Guy intended?
In other words, How many implementations allow, for example,
(setf (symbol-function 'foo) 1.0d0). VaxLisp does not allow this.
I tried (setf (symbol-function 'foo) 'bar) in the two CLs within easy
reach. Both signal errors, and not particularly nice ones either. (I'd
expect something like "illegal value ~S for SYMBOL-FUNCTION", but I get
things like "segmentation-violation".)
2...
3. Under interp 1. consider the following:
(defun foo () (print "hello"))
(setf (symbol-function 'bar) 'foo)
Which of the following are legal?:
(funcall 'bar) ; A
(funcall #'bar) ; B
(funcall (symbol-function 'bar)) ; C
Case C is the only one I am sure is legal. The other two depend on
the ambiguous description of function calling (pg. 58) and APPLY (pg.
107).
Case C should be legal because it should be the same as (funcall 'foo).
Case B should also be legal because #'bar == (function bar) should be
equivalent to (symbol-function 'bar) in a context where bar refers to a
global function (i.e., when there's no lexically enclosing flet or
labels that binds bar), as it does in this case.
One of (:->) the definitions of FUNCTION on pg. 87 states that "FN is
interpreted as if it had appeared in the functional position of a
function invocation". As most of us would agree (but CLtL does not
pin down), the function call (bar) is erroneous (again, CLtL does not
define what should happen when the function definition is illegal or
even unbound). By this definition of FUNCTION then, (function bar) is
erroneous. Up until now, I think most people thought that (bar) and
(funcall (function bar)) were semantically equivalent (i.e., both are
illegal). By your definition of FUNCTION (as being eqiv. to
SYMBOL-FUNCTION in the case of a global function name), the former is
still illegal but the latter is perfectly legal. Yecch! I'll stick
with my reading of FUNCTION.
Case A should be illegal, but CLtL does not explicitly exclude it.
...
Agreed.
...
I guess my point is that I think most implementors followed
interpretation 2 which prevents the kind of confusion where C is legal
but B is not; so we should clarify CLtL in that direction rather than
towards interp 1.
I don't think there is a case where C should be legal and B not.
As I showed above, I think there is.
Whatever interp. is finally chosen, APPLY should be clarified so that
we known exactly what can be applied (and if a symbol is applied, what
exactly can be legally the function definition).
I agree that the definition of APPLY is deficient. For example, it
seems to list explicitly all the things that might be functions and yet
it never mentions closures. Compare this list to that on page 32.
In general, my favorite pages for answering questions concerning what
things are legal as functions are pages 32 (section 2.13) and 59
(section 5.2). Page 59 is, for example, the place where the distinction
between the use of lambda-expressions and symbols as *names* for
functions and their use as function objects is most clearly made.
Thank you for pointing out pg 32. It states that "The result of
evaluating a FUNCTION special form will always be a function." If we
accept this statement. Then under interp. 2:
(setf (symbol-function 'zap) 1.0)
What does this return?:
(function zap) =>
A) 1.0 ; According to your definition of FUNCTION.
B) <<a function that when called will barf>>.
C) Undefined by CL (implementations are encouraged to signal an error).
I hope that I have made my point that interp. 2 is unintuitive (since
most implementations didn't do it that way) and leads to confusion.
-- Nick
∂10-Apr-86 2303 gls@THINK-AQUINAS.ARPA [gls@THINK-AQUINAS.ARPA: setf place]
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 10 Apr 86 23:03:28 PST
Received: from thorlac by GODOT.THINK.COM via CHAOS; Thu, 10 Apr 86 12:12:04 est
Date: Thu, 10 Apr 86 12:13 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: [gls@THINK-AQUINAS.ARPA: setf place]
To: common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
Message-Id: <860410121335.1.GLS@THINK-THORLAC.ARPA>
Date: Thu, 10 Apr 86 11:32 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Date: 8 Apr 86 23:36:00 EST
From: "BACH::NELSON" <nelson%bach.decnet@hudson.dec.com>
Guy, we've had a request from a VAX LISP customer to change our implementation
of SETF. This user reads the description of acceptable places (p. 97) to
mean that if one says (setf (a b) c) and if A has a macro definition, that we
first check for a setf expander for the form (a b), and only macroexpand if we
find no setf expander for the un-macroexpanded form. I consider this an
incorrect reading of the book; I think that the book says that if A has
a macro definition, only the result of the macroexpansion will be used.
Could you tell me what you think the book says? Thanks very much.
Beryl Nelson
nelson@hudson.dec.com
------
I agree that the book is not properly organized here. The list of items on
pp. 94-97 was not intended to be in any particular order, and certainly not
in priority order. However, I can see that the list might be interpreted in
that manner. It should be clear that what your user wants will "do the
right thing" under more sets of circumstances, and it is what I would
expect; but I agree that the book should be made more clear.
--Guy
∂10-Apr-86 2308 hpfclp!diamant@hplabs.ARPA Re: EVAL-WHEN (really symbol-function)
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 10 Apr 86 23:07:34 PST
Received: by hplabs.ARPA ; Thu, 10 Apr 86 23:05:47 pst
Date: Thu, 10 Apr 86 23:05:47 pst
From: hpfclp!diamant@hplabs.ARPA
To: common-lisp@su-ai.ARPA
Subject: Re: EVAL-WHEN (really symbol-function)
I think it is time we back off for a second from what is in the book, and
just think about what makes sense for Common LISP. I would advocate
making the restriction I have suggested explicit: "It is an error to
setf the symbol-function to an object not of type FUNCTION." Also, the
implementation should be at liberty to store the functional interpretation
of a lambda or symbol if that is what setf is given. Note that this
doesn't restrict the implementation from setting it in the case of a macro
or special form. My real concern is that no gain is made by making
the function cell completely general, and there are some losses (consistency
with (setf (macro-function...)) and performance). It seems every time
we get into a discussion about an ambiguity, we always make a change that
tends to make the language more complicated. Why can't we try for simplicity
this time (I really don't see that we are losing anything)?
All this hidden hash concept does for you is give the user one function cell
and the implementation an other one. What good is the user function cell if
the system isn't even using it?
If anybody has a reason why the restriction I mention above interferes with
execution of correct code, please say so (don't tell me about doing an
EQL test before and after a (setf (symbol-function...)) because that is what
we are disputing. I mean when would someone legitimately write a piece of
Common LISP with non-function items in the function cell (unless they
were simply using it as a value cell)? Until someone can generate such an
example, I see no reason why some people are so tenaciously insisting that
anything can be stored in the funtion cell.
Consider what happens if you allow arbitrary objects in the function cell
as in the following example:
(setf x '(lambda () "Hi"))
(setf (symbol-function 'y) x)
(setf (third x) "Bye")
(y)
What is this supposed to return? In an implementation which guarantees that
the value stored really is EQL to the one given, it seems reasonable that
"Bye" would be returned. But in order to make that work, the implementation
couldn't use the hidden hash method because it wouldn't reflect the change.
It would still have to interpret each time! You can always say that it doesn't
have to reflect the list surgery, but then what's the point of requiring that
the result be EQL?
From: hplabs!NGALL@G.BBN.COM
Date: Wed, 9 Apr 86 21:08:05 GMT
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@cs.ucl.ac.uk>
Subject: Re: EVAL-WHEN (really symbol-function)
Date: 8 Apr 1986 17:34-EST
From: NGALL@arpa.bbng
3. Under interp 1. consider the following:
(defun foo () (print "hello"))
(setf (symbol-function 'bar) 'foo)
Which of the following are legal?:
(funcall 'bar) ; A
(funcall #'bar) ; B
(funcall (symbol-function 'bar)) ; C
Case C is the only one I am sure is legal. The other two depend on
the ambiguous description of function calling (pg. 58) and APPLY (pg.
107).
Case C should be legal because it should be the same as (funcall 'foo).
Case B should also be legal because #'bar == (function bar) should be
equivalent to (symbol-function 'bar) in a context where bar refers to a
global function (i.e., when there's no lexically enclosing flet or
labels that binds bar), as it does in this case.
One of (:->) the definitions of FUNCTION on pg. 87 states that "FN is
interpreted as if it had appeared in the functional position of a
function invocation". As most of us would agree (but CLtL does not
pin down), the function call (bar) is erroneous (again, CLtL does not
define what should happen when the function definition is illegal or
even unbound). By this definition of FUNCTION then, (function bar) is
erroneous. Up until now, I think most people thought that (bar) and
(funcall (function bar)) were semantically equivalent (i.e., both are
illegal). By your definition of FUNCTION (as being eqiv. to
SYMBOL-FUNCTION in the case of a global function name), the former is
still illegal but the latter is perfectly legal. Yecch! I'll stick
with my reading of FUNCTION.
The definition of FUNCTION (on page 87) also says:
"If fn is a symbol, the functional definition associated with that symbol is
returned; see symbol-function." Yecch is right, but that's what it says!
...
I guess my point is that I think most implementors followed
interpretation 2 which prevents the kind of confusion where C is legal
but B is not; so we should clarify CLtL in that direction rather than
towards interp 1.
I don't think there is a case where C should be legal and B not.
As I showed above, I think there is.
Thank you for pointing out pg 32. It states that "The result of
evaluating a FUNCTION special form will always be a function." If we
accept this statement. Then under interp. 2:
(setf (symbol-function 'zap) 1.0)
What does this return?:
(function zap) =>
A) 1.0 ; According to your definition of FUNCTION.
B) <<a function that when called will barf>>.
C) Undefined by CL (implementations are encouraged to signal an error).
I hope that I have made my point that interp. 2 is unintuitive (since
most implementations didn't do it that way) and leads to confusion.
Well, based on the statement I quoted above from FUNCTION, it must be A, but
based on the statement you quoted from page 32, that is impossible. Again,
I can only conclude that only objects of type FUNCTION should be allowed
in the function cell! I still believe that the only way the statements
about FUNCTION (page 32 and 87) can be interpreted consistently is if
function cells are only allowed to contain objects which are FUNCTIONP.
Equally important is the point which Nick makes, namely that it is much
more intuitive (and consistent with (setf (macro-function...)) (which states
that "the value installed must be a function ...") Indeed, SYMBOL-FUNCTION
says much the same thing: "the definition may be a function or an object
========
representing a special form or macro [ underlining added by me]"
John
∂11-Apr-86 0706 DLW@SAPSUCKER.SCRC.Symbolics.COM Re: EVAL-WHEN (really symbol-function)
Received: from [192.10.41.223] by SU-AI.ARPA with TCP; 11 Apr 86 07:04:07 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 7537; Fri 11-Apr-86 10:03:07 EST
Date: Fri, 11 Apr 86 10:04 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Re: EVAL-WHEN (really symbol-function)
To: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 11 Apr 86 02:05 EST from hpfclp!diamant@hplabs.ARPA
Message-ID: <860411100408.9.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Thu, 10 Apr 86 23:05:47 pst
From: hpfclp!diamant@hplabs.ARPA
I think it is time we back off for a second from what is in the book, and
just think about what makes sense for Common LISP. I would advocate
making the restriction I have suggested explicit: "It is an error to
setf the symbol-function to an object not of type FUNCTION."
While it's true in general that we must consider what seems to be the
best language design, it is not true that we should adopt the attitude
that Common Lisp's definition should, at this point, be changed every
time we see something that we think could be changed for the better
(even assuming a strong concensus). We have long since reached the
point at which stability of the definition of the language is an
important issue. The detailed arguments to this effect have been made
several times already, so I won't repeat them; I'd just like to throw in
this reminder. I presume that the technical committee will write up a
set of guidelines regarding this tradeoff.
∂11-Apr-86 0801 NGALL@G.BBN.COM Re: SYMBOL-FUNCTION
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 11 Apr 86 08:01:26 PST
Date: 11 Apr 1986 11:02-EST
Sender: NGALL@G.BBN.COM
Subject: Re: SYMBOL-FUNCTION
From: NGALL@G.BBN.COM
To: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]11-Apr-86 11:02:34.NGALL>
In-Reply-To: The message of Thu, 10 Apr 86 23:05:47 pst from hpfclp!diamant@hplabs.ARPA
Date: Thu, 10 Apr 86 23:05:47 pst
From: hpfclp!diamant@hplabs.ARPA
To: common-lisp@su-ai.ARPA
Subject: Re: EVAL-WHEN (really symbol-function)
I think it is time we back off for a second from what is in the book, and
just think about what makes sense for Common LISP. I would advocate
making the restriction I have suggested explicit: "It is an error to
setf the symbol-function to an object not of type FUNCTION." Also, the
Yes, I agree that we should restrict what can be assigned to
SYMBOL-FUNCTION, but it cannot be based on the the type FUNCTION as it
is currently defined, since (FUNCTIONP 'CAR) is true. This would
allow (SETF (SYMBOL-FUNCTION 'FOO) 'CAR), which is what we are trying
to prevent.
I propose that we adopt the distinction between a FUNCTION OBJECT
and a FUNCTION NAME mentioned on pg. 59. By this
definition, lambda-expressions and symbols would be FUNCTION NAMES,
but NOT function objects (this restriction is mine, pg. 59 would need
to be 'clarified' :->). Compiled-code objects and closures would be
the ONLY CL defined FUNCTIONS (i.e., FUNCTION DEFINITIONS or FUNCTION
OBJECTS). (Cf. pg 89 for explanation of why closures are sufficient
for all uncompiled functions).
Thus type FUNCTION would have two subtypes (not necessarily disjoint
in all implementations, since some might use lambda-expressions as
function objects): FUNCTION-NAME and FUNCTION-OBJECT (I would prefer
to call it FUNCTION-DEFINITION so we wouldn't have to say things like
"an object of type function-object").
If the value to be assigned to SYMBOL-FUNCTION is a FUNCTION-NAME
(note that this test should be done first), then the FUNCTION OBJECT
that it NAMES is assigned (and it is an error if the NAME does not
name a function object (which can happen only with symbols). In the
case of a lambda-expression, this means that the implementation turns
it into a closure or a compiled-code object. Note that the following
two assignments would still be quite different:
(let ((x 1))
(setf (symbol-function 'foo) '(lambda () x)) ; x is implicitly special
(setf (symbol-function 'foo) #'(lambda () x))) ; x is lexical
In the case of a symbol (e.g., FOO) that names a FUNCTION OBJECT, it would be
undefined whether or not
(eql (symbol-function 'foo)
(symbol-function (prog1 'bar (setf (symbol-function 'bar) 'foo))))
Also, note that
(setf (symbol-function '<<symbol>>) '<<function-name>>)
would be unusual among SETFs in that the value returned by the setf
would not be EQL to the value subsequently returned by the accessor
form.
Such a definition would also clear up the definition of FUNCTION. The
arg. to function must be a FUNCTION-NAME and the result will be a
FUNCTION-OBJECT. It would also clear up APPLY and FUNCALL. The first
arg. to both functions must be of type FUNCTION. In the case of a
FUNCTION-OBJECT, it is 'used' directly. In the case of a
FUNCTION-NAME, the FUNCTION-OBJECT that it names will be 'used'.
This will also clear up wording like "The argument...should be a
function...in a form acceptable to the FUNCTION special form" (pg.
314). Instead, we merely say, "The argument must be a function name."
implementation should be at liberty to store the functional interpretation
of a lambda or symbol if that is what setf is given. Note that this
doesn't restrict the implementation from setting it in the case of a macro
or special form. My real concern is that no gain is made by making
the function cell completely general, and there are some losses (consistency
with (setf (macro-function...)) and performance). It seems every time
we get into a discussion about an ambiguity, we always make a change that
tends to make the language more complicated. Why can't we try for simplicity
this time (I really don't see that we are losing anything)?
All this hidden hash concept does for you is give the user one function cell
and the implementation an other one. What good is the user function cell if
the system isn't even using it?
If anybody has a reason why the restriction I mention above interferes with
execution of correct code, please say so (don't tell me about doing an
EQL test before and after a (setf (symbol-function...)) because that is what
we are disputing. I mean when would someone legitimately write a piece of
Common LISP with non-function items in the function cell (unless they
were simply using it as a value cell)? Until someone can generate such an
example, I see no reason why some people are so tenaciously insisting that
anything can be stored in the funtion cell.
If I directly assign a function object using (SETF (SYMBOL-FUNCTION...)...),
I would like it guaranteed that (SYMBOL-FUNCTION...) return the EQL
function object (not that this definitely does not hold for names).
In trace packages, encapsulations, etc., the program putting in a
wrapper may need to know if the current function definition for a
symbol is EQL to the one it SETF in there. My proposal allows this.
Consider what happens if you allow arbitrary objects in the function cell
as in the following example:
(setf x '(lambda () "Hi"))
(setf (symbol-function 'y) x)
(setf (third x) "Bye")
(y)
What is this supposed to return? In an implementation which guarantees that
Under my proposal, it would be undefined, since an implementation is
free to use the lambda-expression directly, closure it, compile it, or
just copy it.
-- Nick
∂11-Apr-86 0827 FAHLMAN@C.CS.CMU.EDU SYMBOL-FUNCTION
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 11 Apr 86 08:27:10 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 11 Apr 86 11:26:40-EST
Date: Fri, 11 Apr 1986 11:26 EST
Message-ID: <FAHLMAN.12198002066.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: NGALL@BBNG.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: SYMBOL-FUNCTION
In-reply-to: Msg of 11 Apr 1986 11:02-EST from NGALL at G.BBN.COM
I propose that we adopt the distinction between a FUNCTION OBJECT
and a FUNCTION NAME mentioned on pg. 59. By this
definition, lambda-expressions and symbols would be FUNCTION NAMES,
but NOT function objects (this restriction is mine, pg. 59 would need
to be 'clarified' :->). Compiled-code objects and closures would be
the ONLY CL defined FUNCTIONS (i.e., FUNCTION DEFINITIONS or FUNCTION
OBJECTS).
I agree that something like this is badly needed in the next official
document (presumably the one for ANSI) to clear up all the ambiguity
about what is a function. I'm not sure that we want to make lambda
expressions function names rather than function objects, however. I'll
have to think about that one.
-- Scott
∂11-Apr-86 1339 greek%bach.decnet@hudson.dec.com Questions and an offer concerning "EVAL-WHEN" issues.
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 11 Apr 86 13:38:36 PST
Date: 11 Apr 86 16:21:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: Questions and an offer concerning "EVAL-WHEN" issues.
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Here is some food for thought concerning the "EVAL-WHEN" issues.
Let's assume that we define the "global environment" as that
information established by the read-eval-print loop or loaded from
files.
And let's define the "compilation environment" as the information
established by compilations.
How about these for three rules (certainly open to debate).
1. The compiler is required to use information in the global
environment.
2. The compiler is required to use information in the compilation
environment established by prior compilations.
3. The compiler is not allowed to affect the global environment.
Many schemes can be devised to implement these rules, but no matter how
clever they get, it's tough to solve the following problems.
o How does the user alter the readtable for the duration of a
compilation but not permanently?
o How does the compiler handle package functions in the source file
without actually evaluating them?
o What about necessary uses of (EVAL-WHEN (COMPILE) ...), such as
DEFCONSTANTs used as keys with the CASE macro?
o Etc., etc.
Thinking about schemes to implement these rules also brings up
questions of the organization of source files. For example, is it OK
for a file to contain contradictory proclamations:
(PROCLAIM '(FIXNUM *FOO*))
.
.
(PROCLAIM '(SIMPLE-STRING *FOO*))
In other words, is a proclamation static or "scoped"? Without getting
too clever, you can write a source file which knows whether the
compiler is one-pass or multi-pass.
How about the question of which "top-level" forms the compiler pays
special attention to. For example, we know that the compiler notices
a DEFMACRO so that it can expand such macros later on. What makes it
notice the macro?
1. The presence of the LOAD situation (which is the default).
2. The presence of a hidden situation, say called COMPILER-NOTICE
(this must also be the default).
3. Nothing in particular, it always looks at it.
If you think a bit, you'll find problem with all three of these
theories. In particular, how do you tell the compiler to notice the
macro definition but not dump it? What else does the compiler pay
special attention to? How about DEFUN? Can I call a function from
a macro expander and expect that to work? How do PROVIDE and REQUIRE
work during a compilation?
Then there is the age-old question of whether an unqualified symbol
should be loaded into the package that was current at compilation time
or the package that is current at load time. If the latter, how do you
distinguish an unqualified symbol from one that was explicity qualified
with the package current at compilation time?
Should there be a function to flush the compilation environment? One
might use this in between compilation of two sets of related files.
This causes one to wonder if the compilation environment shouldn't be
trashed after every compilation, forcing users to compile related files
using PROVIDE and REQUIRE (see above).
If people are interested in compiling a list of compilation environment
questions, so that we have a place to start in solving these problems,
I'd be happy to collect the questions and compile a complete list.
- Paul
------
∂11-Apr-86 1342 NGALL@G.BBN.COM Are isomorphic structures EQUAL?
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 11 Apr 86 13:42:22 PST
Date: 11 Apr 1986 16:43-EST
Sender: NGALL@G.BBN.COM
Subject: Are isomorphic structures EQUAL?
From: NGALL@G.BBN.COM
To: common-lisp@SU-AI.ARPA, nlp@LABS-B.BBN.COM
Message-ID: <[G.BBN.COM]11-Apr-86 16:43:13.NGALL>
I don't want to reopen the discussion that we had about equality a
while back, but someone in my group just tripped over an ambiguity in
the manual.
She was using DEFSTRUCT with the (:TYPE ...) option and using EQUAL to
compare structures and everything worked fine since EQUAL did a
component-wise equality test.
Then she got bold and decided to let DEFSTRUCT choose the
representation, so she left off the (:TYPE ...) option. Low and
behold, EQUAL did not do a component-wise equality test, it tested for
EQL!
So she looked at the def. on page 80 where it said "Certain objects
that have components are EQUAL if they are of the same type and
corresponding components are EQUAL." Unfortunately, the rest of the
definition did not make it at all clear whether or not objects created
by DEFSTRUCT were among these "Certain objects". Looking on the next
page at the def. of EQUALP (which happened to do a component-wise
equality test), she read "Objects that have components..." The only
difference was the word "Certain"!
So we tried it on another CL (SymbolicsCL), and got the same behavior
(as with VaxLisp). Which leads me to almost believe that EQUAL NOT
supposed to to a component-wise test for equality. Except...
What happens to implementations that want to represent structures
using plain old vectors? How will EQUAL distinguish vectors from
structure-vectors?
This interaction of DEFSTRUCT/EQUAL is going to cause a lot of bugs.
People are going to prototype structues using the (:TYPE LIST) option
and use EQUAL to do equality tests. Then when they remove the :TYPE
option, KaBoom!
There will be no way to do a component-wise test (using EQUAL on each
component) on two structures unless one writes a structure-specific
equality predicate.
Therefore, I propose that two structures of the same type that are
created by DEFSTRUCT (regardless of the :TYPE option) be tested for
equality component-wise and that the CLtL make this clear.
Until then, she can get by with EQUALP (since her structures don't
conatin strings, floats, etc.).
-- Nick
∂11-Apr-86 1716 hpfclp!diamant@hplabs.ARPA Re: SYMBOL-FUNCTION
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 11 Apr 86 17:16:35 PST
Received: by hplabs.ARPA ; Fri, 11 Apr 86 17:14:47 pst
Date: Fri, 11 Apr 86 17:14:47 pst
From: hpfclp!diamant@hplabs.ARPA
To: common-lisp@su-ai.ARPA
Subject: Re: SYMBOL-FUNCTION
I am quite satisfied with Nick's proposal. The distinction between FUNCTION
OBJECT and FUNCTION NAME is an important one, and the proposal handles it
in an intuitive way. The EQL requirement for function objects (but not
function names) seems reasonable as well. Thanks, Nick, for crystallizing the
concepts we have been discussing.
By the way, I don't consider this proposal an incompatible change to
CLtL. Rather, it is a clarification which eliminates inconsistencies in the
current specification.
This is, in fact, what we have implemented independently of this discussion.
It is probably close to what most implementations do.
John Diamant
Systems Software Operation UUCP: {ihnp4!hpfcla,hplabs}!hpfclp!diamant
Hewlett Packard Co. ARPA/CSNET: diamant%hpfclp@hplabs
Fort Collins, CO
∂11-Apr-86 1948 Pavel.pa@Xerox.COM unwind-protect
Received: from XEROX.COM by SU-AI.ARPA with TCP; 11 Apr 86 19:47:07 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 11 APR 86 19:47:59 PST
Date: 11 Apr 86 19:47 PST
From: Pavel.pa@Xerox.COM
Subject: unwind-protect
To: common-lisp@SU-AI.ARPA
cc: vanMelle.pa@Xerox.COM,Pavel.pa@Xerox.COM
Format: TEdit
Message-ID: <860411-194759-1452@Xerox>
What is the result of this code:
(proclaim '(special *foo*))
(let* ((x 'good)
(*foo* x))
(block bar
(unwind-protect
(let ((*foo* 'bad))
(return-from bar))
(setq x *foo*)))
x)
The Zetalisp manual says it will return GOOD, but the silver book is
silent on the issue. This should be clarified.
Pavel
∂14-Apr-86 1337 cfry%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU Successor to eval-when?
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 14 Apr 86 01:59:44 PST
Received: from DUANE.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 14 Apr 86 05:01-EST
Date: Mon, 14 Apr 86 05:00 EST
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
Subject: Successor to eval-when?
To: RAM@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA
In-Reply-To: <RAM.12197657052.BABYL@C.CS.CMU.EDU>
Message-ID: <860414050020.7.CFRY@DUANE.AI.MIT.EDU>
Received: from MC.LCS.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 10 Apr 86 04:17-EST
Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 10 Apr 86 04:16:41 EST
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 10 Apr 86 00:50:38 PST
Received: ID <RAM@C.CS.CMU.EDU>; Thu 10 Apr 86 03:51:25-EST
Date: Thu, 10 Apr 1986 03:51 EST
Message-ID: <RAM.12197657052.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Successor to eval-when?
If anyone has an idea for a replacement to eval-when, speak up. I
don't have any idea of anything that would be better. There seem to
be two main reasons people are upset with eval-when:
1] It is currently ill-defined.
2] It is hard to understand.
I believe that the first problem is fairly easy to fix; I suspect that
the second problem is inherent in the nature of the beast.
Rob
It is also poorly named according to the semantics that people
seem to have agreed upon.
∂14-Apr-86 1540 JAR@MC.LCS.MIT.EDU Are isomorphic structures EQUAL?
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 14 Apr 86 15:40:32 PST
Date: Mon, 14 Apr 86 18:41:30 EST
From: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
Subject: Are isomorphic structures EQUAL?
To: NGALL@BBNG.ARPA
cc: nlp@BBN-LABS-B.ARPA, common-lisp@SU-AI.ARPA
In-reply-to: Msg of 11 Apr 1986 16:43-EST from NGALL at G.BBN.COM
Message-ID: <[MC.LCS.MIT.EDU].884004.860414.JAR>
Date: 11 Apr 1986 16:43-EST
From: NGALL at G.BBN.COM
What happens to implementations that want to represent structures
using plain old vectors?...
If this isn't forbidden by the language spec, it ought to be.
Jonathan
∂14-Apr-86 1630 GJC@MC.LCS.MIT.EDU
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 14 Apr 86 16:29:55 PST
Date: Mon, 14 Apr 86 18:43:38 EST
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
To: common-lisp@SU-AI.ARPA
Message-ID: <[MC.LCS.MIT.EDU].884011.860414.GJC>
A user pointed out that the CL manual specifies that
(FBOUNDP 'SETQ) must be T (true). And that also symbol-function
of a special form should return <something>. Is this a correct reading?
There are a few uses of the word "may be" on that page that could be
confusing.
∂14-Apr-86 1632 cfry%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU Successor to eval-when?
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 14 Apr 86 01:59:44 PST
Received: from DUANE.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 14 Apr 86 05:01-EST
Date: Mon, 14 Apr 86 05:00 EST
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
Subject: Successor to eval-when?
To: RAM@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA
In-Reply-To: <RAM.12197657052.BABYL@C.CS.CMU.EDU>
Message-ID: <860414050020.7.CFRY@DUANE.AI.MIT.EDU>
Received: from MC.LCS.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 10 Apr 86 04:17-EST
Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 10 Apr 86 04:16:41 EST
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 10 Apr 86 00:50:38 PST
Received: ID <RAM@C.CS.CMU.EDU>; Thu 10 Apr 86 03:51:25-EST
Date: Thu, 10 Apr 1986 03:51 EST
Message-ID: <RAM.12197657052.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Successor to eval-when?
If anyone has an idea for a replacement to eval-when, speak up. I
don't have any idea of anything that would be better. There seem to
be two main reasons people are upset with eval-when:
1] It is currently ill-defined.
2] It is hard to understand.
I believe that the first problem is fairly easy to fix; I suspect that
the second problem is inherent in the nature of the beast.
Rob
It is also poorly named according to the semantics that people
seem to have agreed upon.
∂14-Apr-86 1646 RPG sign me up
∂14-Apr-86 1332 marchett%cod@nosc.ARPA sign me up
Received: from NOSC.ARPA by SU-AI.ARPA with TCP; 14 Apr 86 10:01:36 PST
Received: by bass.ARPA (5.31/4.7)
id AA12999; Mon, 14 Apr 86 10:02:43 PST
Received: by cod.ARPA (5.31/4.7)
id AA04613; Mon, 14 Apr 86 10:02:39 PST
Date: Mon, 14 Apr 86 10:02:39 PST
From: David J. Marchette <marchett%cod@nosc.ARPA>
Message-Id: <8604141802.AA04613@cod.ARPA>
To: common-lisp-request@su-ai
Subject: sign me up
please add me to your mailing list. If this is the
second time you have seen this, it's because I goofed.
***********************************
* David Marchette *
* *
* marchett@cod.UUCP *
* marchett@noscvax.UUCP *
* marchett@cod.nosc.MIL *
* ucbvax!sdcsvax!noscvax!marchett *
* *
* Naval Ocean Systems Center *
* Code 421 *
* 271 Catalina Blvd. *
* San Diego, CA 92152 *
* *
* Ph. (619) 225-6571 *
***********************************
(add-dis common)
"marchett%cod"@nosc.ARPA
∂14-Apr-86 1723 DCP@SCRC-STONY-BROOK.ARPA unwind-protect
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 14 Apr 86 05:56:19 PST
Received: from FIREBIRD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 462563; Mon 14-Apr-86 08:56:18-EST
Date: Mon, 14 Apr 86 08:53 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: unwind-protect
To: Pavel.pa@Xerox.COM, common-lisp@SU-AI.ARPA
cc: vanMelle.pa@Xerox.COM
In-Reply-To: <860411-194759-1452@Xerox>
Message-ID: <860414085344.8.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: 11 Apr 86 19:47 PST
From: Pavel.pa@Xerox.COM
What is the result of this code:
(proclaim '(special *foo*))
(let* ((x 'good)
(*foo* x))
(block bar
(unwind-protect
(let ((*foo* 'bad))
(return-from bar))
(setq x *foo*)))
x)
The Zetalisp manual says it will return GOOD, but the silver book is
silent on the issue. This should be clarified.
The only possible clarification is an infinite enumeration of scoping
examples. The scope of the binding of *FOO* to 'BAD does NOT include
the SETQ in the cleanup clause. In other words, the ONLY time *FOO* has
the value BAD is during the (dynamic extent) of the body of the LET
clause. The cleanup is outside the LET and therefore the dynamic extent
has finished.
∂14-Apr-86 1812 gls@THINK-AQUINAS.ARPA unwind-protect
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 14 Apr 86 10:11:46 PST
Received: from sebastian by GODOT.THINK.COM via CHAOS; Mon, 14 Apr 86 13:11:10 est
Date: Mon, 14 Apr 86 13:12 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: unwind-protect
To: Pavel.pa@Xerox.COM, common-lisp@SU-AI.ARPA
Cc: vanMelle.pa@Xerox.COM, gls@THINK-AQUINAS.ARPA
In-Reply-To: <860411-194759-1452@Xerox>
Message-Id: <860414131231.1.GLS@THINK-SEBASTIAN.ARPA>
Date: 11 Apr 86 19:47 PST
From: Pavel.pa@Xerox.COM
What is the result of this code:
(proclaim '(special *foo*))
(let* ((x 'good)
(*foo* x))
(block bar
(unwind-protect
(let ((*foo* 'bad))
(return-from bar))
(setq x *foo*)))
x)
The Zetalisp manual says it will return GOOD, but the silver book is
silent on the issue. This should be clarified.
Pavel
I also believe that it should return GOOD. There should be some prose
in the silver book (not there now) that says that the cleanup-forms
are executed in the dynamic environment of the unwind-protect form
itself. Loosely speaking, it is as if there were a TAGBODY tag just
in front of the first cleanup form, and any exit causes a transfer of
control to that tag as if by a GO (but with further actions pending,
such as the returning of a value or resumption of a THROW). This will
be very hard to word properly.
--Guy
∂14-Apr-86 2117 DT50@A.CS.CMU.EDU bit fields in defstruct
Received: from A.CS.CMU.EDU by SU-AI.ARPA with TCP; 14 Apr 86 21:16:58 PST
Date: 15 Apr 86 00:17 EST
From: Dave.Touretzky@A.CS.CMU.EDU
To: common-lisp@SU-AI.ARPA
Subject: bit fields in defstruct
Can someone tell me why Common Lisp defstruct doesn't support bit fields?
This is a Zetalisp feature that I make heavy use of. The equivalent feature
in Common Lisp would look something like:
(defstruct thingie
(foo 'default-foo-value)
((low-bar (byte 8 0))
(mid-bar (byte 8 8) #x00 :read-only t) ;filled by constructor
(high-bar (byte 8 12) #x1a))
(baz 'default-baz-value))
This makes THINGIE a vector with 4 elements (counting the structure name);
the second element is an integer with default value #x1a0000. The structure
has 5 access functions:
THINGIE-FOO
THINGIE-LOW-BAR
THINGIE-MID-BAR
THINGIE-HIGH-BAR
THINGIE-BAZ
The access function for -BAR slots expands to a LDB, and the SETF macro
expands to a DPB. The knowledge that three of the slots of a THINGIE are
bit fields of the same integer is hidden from the rest of the program.
The reason I need this feature is I am building thousands of instances of a
particular structure, and the difference between representing half a dozen
bit fields with one integer versus six integers is significant in terms of
memory cost. I don't think a user should build his own access functions for
bit fields; I think defstruct should do that for him.
-- Dave
PS: I suppose if defstruct were highly optimizing one could declare six
fields of :TYPE BIT and expect them to be packed into one word. This
doesn't solve everything though; in some cases (like when communicating
with external programs) one wants to specify the exact postion of each bit
field in a word. Also, one might want to have overlapping bit fields in the
same word, such as three 1-bit fields and a 3-bit field that covers them.
∂15-Apr-86 0412 GJC@MC.LCS.MIT.EDU unwind-protect description
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 15 Apr 86 04:12:37 PST
Date: Tue, 15 Apr 86 07:13:50 EST
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Subject: unwind-protect description
To: gls@AQUINAS.THINK.COM
cc: common-lisp@SU-AI.ARPA
In-reply-to: Msg of Mon 14 Apr 86 13:12 EST from Guy Steele <gls at THINK-AQUINAS.ARPA>
Message-ID: <[MC.LCS.MIT.EDU].884886.860415.GJC>
You could word it by giving an implementation of unwind-protect as a macro
in terms of other primitives. The first step is of course
(unwind-protect body1 body2) => (*unwind-protect #'(lambda () body1)
#'(lambda () body2))
Which makes the environment issue clear. Then, given a form of catch
and throw called %CATCH and %THROW that do not take a TAG first argument
you can implement common-lisp CATCH and THROW while taking care of unwind
protect quite neatly.
∂15-Apr-86 0417 GJC@MC.LCS.MIT.EDU contents of SYMBOL-FUNCTION for special forms.
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 15 Apr 86 04:17:46 PST
Date: Tue, 15 Apr 86 07:18:49 EST
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Subject: contents of SYMBOL-FUNCTION for special forms.
To: common-lisp@SU-AI.ARPA
In-reply-to: Msg of Mon 14 Apr 86 05:00 EST from Christopher Fry <cfry at OZ.AI.MIT.EDU>
Message-ID: <[MC.LCS.MIT.EDU].884888.860415.GJC>
Intent clarification: Is the manual really trying to say that
(SYMBOL-FUNCTION 'SETQ) *must* return something when it says that it
"may return something for special forms and macros" ???
Do we really want (FBOUNDP 'SETQ) => T?
∂15-Apr-86 0753 DCP@SCRC-QUABBIN.ARPA bit fields in defstruct
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 15 Apr 86 07:52:52 PST
Received: from FIREBIRD.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 264679; Tue 15-Apr-86 09:44:46-EST
Date: Tue, 15 Apr 86 09:40 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: bit fields in defstruct
To: Dave.Touretzky@A.CS.CMU.EDU, common-lisp@SU-AI.ARPA
In-Reply-To: The message of 15 Apr 86 00:17 EST from Dave.Touretzky@A.CS.CMU.EDU
Message-ID: <860415094007.3.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: 15 Apr 86 00:17 EST
From: Dave.Touretzky@A.CS.CMU.EDU
Can someone tell me why Common Lisp defstruct doesn't support bit fields?
This is a Zetalisp feature that I make heavy use of. The equivalent feature
in Common Lisp would look something like:
(defstruct thingie
(foo 'default-foo-value)
((low-bar (byte 8 0))
(mid-bar (byte 8 8) #x00 :read-only t) ;filled by constructor
(high-bar (byte 8 12) #x1a))
(baz 'default-baz-value))
This makes THINGIE a vector with 4 elements (counting the structure name);
the second element is an integer with default value #x1a0000. The structure
has 5 access functions:
THINGIE-FOO
THINGIE-LOW-BAR
THINGIE-MID-BAR
THINGIE-HIGH-BAR
THINGIE-BAZ
The access function for -BAR slots expands to a LDB, and the SETF macro
expands to a DPB. The knowledge that three of the slots of a THINGIE are
bit fields of the same integer is hidden from the rest of the program.
The reason I need this feature is I am building thousands of instances of a
particular structure, and the difference between representing half a dozen
bit fields with one integer versus six integers is significant in terms of
memory cost. I don't think a user should build his own access functions for
bit fields; I think defstruct should do that for him.
Two things:
(1) Syntax. What do you think about
(defstruct thingie
(foo 'default-foo-value)
((low-bar 0 :byte-field (byte 8 0))
(mid-bar #x00 :byte-field (byte 8 8) :read-only t)
(high-bar #x1A :byte-field (byte 8 12)))
(baz 'default-baz-value))
instead of yours? Yes, I know the default value must be specified, but
this syntax is consistent with non-nested syntax. I propose that a
value of NIL means that it isn't filled in (and isn't forced to zero
(see [3]).
(2) Performance. Users should be wary that doing such things has
efficiency issues depending on the boundaries between fixnum and bignum.
That is, since the fields are integers, a user could accidentally go
consing a lot of bignums, where a normal defstruct wouldn't.
[3, In your example, mid-bar and high-bar overlap. mid-bar gets filled
in by the constructor, and high-bar has a default. How are these
merged, since they overlap?]
PS: I suppose if defstruct were highly optimizing one could declare six
fields of :TYPE BIT and expect them to be packed into one word. This
doesn't solve everything though; in some cases (like when communicating
with external programs) one wants to specify the exact postion of each bit
field in a word. Also, one might want to have overlapping bit fields in the
same word, such as three 1-bit fields and a 3-bit field that covers them.
Indeed, this is one of the motivations for Symbolics extending defstruct
along these lines. Normal users don't need this; it is usually used for
interfacing to hardware device registers, and sometimes network packets
that have overlapping fields themselves.
∂15-Apr-86 1028 LOOSEMORE@UTAH-20.ARPA block/tagbody and catch/throw
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 15 Apr 86 10:28:04 PST
Date: Tue 15 Apr 86 11:28:18-MST
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: block/tagbody and catch/throw
To: common-lisp@SU-AI.ARPA
Message-ID: <12199072800.26.LOOSEMORE@UTAH-20.ARPA>
Am I the only person who finds the descriptions of the interaction between
block/tagbody and catch/throw in CLtL confusing? On both pages 120 and 131,
it's mentioned that the lexical scoping of the block/tag names "has
consequences that may be suprising to users". What are these consequences?
After being told that my intuitions about their behavior may be wrong, it's
confusing to be told in the very next sentence that the examples work "as
one might expect"; at this point, I don't really know *what* to expect! It
would be helpful to describe the behavior of the examples in more detail
instead of resorting to hand-waving. The reference to "breaking up catchers"
in the following paragraph should also be explained in more detail.
-Sandra
-------
∂15-Apr-86 1113 RAM@C.CS.CMU.EDU block/tagbody and catch/throw
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Apr 86 11:13:40 PST
Received: ID <RAM@C.CS.CMU.EDU>; Tue 15 Apr 86 14:03:16-EST
Date: Tue, 15 Apr 1986 14:03 EST
Message-ID: <RAM.12199079152.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: block/tagbody and catch/throw
In-reply-to: Msg of 15 Apr 1986 13:28-EST from SANDRA <LOOSEMORE at UTAH-20.ARPA>
There is no language-level interaction between catch and throw and
the lexical control mechanisms. To someone who understands lexical
scoping, RETURN and GO do "what one might expect." The tag or block
referred to is the one lexically apparent at the point of the GO or
RETURN.
People more familiar with dynamic scoping "may be surprised",
since the lexically apparent tag or block is not necessarly the
dynamically innermost one.
GO and RETURN sometimes need to remove crap from the stack in most
implementations. This may involve undoing special bindings and
"breaking up catchers." This is a feature of the implementation, not
the language.
Rob
∂15-Apr-86 1124 Daniels.pa@Xerox.COM Re: unwind-protect description
Received: from XEROX.COM by SU-AI.ARPA with TCP; 15 Apr 86 11:24:39 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 15 APR 86 11:24:22 PST
Date: 15 Apr 86 11:22 PST
From: Daniels.pa@Xerox.COM
Subject: Re: unwind-protect description
In-reply-to: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>'s message of Tue,
15 Apr 86 07:13:50 EST
To: GJC@MC.LCS.MIT.EDU
cc: gls@AQUINAS.THINK.COM, common-lisp@SU-AI.ARPA
Message-ID: <860415-112422-1346@Xerox>
"(unwind-protect body1 body2) => (*unwind-protect #'(lambda () body1)
#'(lambda () body2))
Which makes the environment issue clear"
This only addresses the lexical environment of the cleanup forms. It
says nothing about the dynamic environment.
-- Andy. --
∂15-Apr-86 1225 DCP@ALLEGHENY.SCRC.Symbolics.COM block/tagbody and catch/throw
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 15 Apr 86 12:25:14 PST
Received: from FIREBIRD.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 12323; Tue 15-Apr-86 15:24:52-EST
Date: Tue, 15 Apr 86 15:22 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: block/tagbody and catch/throw
To: SANDRA <LOOSEMORE@UTAH-20.ARPA>, Rob MacLachlan <RAM@C.CS.CMU.EDU>,
common-lisp@SU-AI.ARPA
In-Reply-To: <12199072800.26.LOOSEMORE@UTAH-20.ARPA>,
<RAM.12199079152.BABYL@C.CS.CMU.EDU>
Message-ID: <860415152211.9.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Tue 15 Apr 86 11:28:18-MST
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Am I the only person who finds the descriptions of the interaction between
block/tagbody and catch/throw in CLtL confusing? On both pages 120 and 131,
it's mentioned that the lexical scoping of the block/tag names "has
consequences that may be suprising to users". What are these consequences?
After being told that my intuitions about their behavior may be wrong, it's
confusing to be told in the very next sentence that the examples work "as
one might expect"; at this point, I don't really know *what* to expect! It
would be helpful to describe the behavior of the examples in more detail
instead of resorting to hand-waving. The reference to "breaking up catchers"
in the following paragraph should also be explained in more detail.
block/tagbody have lexical scope and dynamic extent. catch/throw have
dynamic scope and dynamic extent. Things work 'as one might expect' if
you fully understand that. If you don't fully understand that, it may
have "consequences that may be surprising." Granted the manual could
probably use improving.
Date: Tue, 15 Apr 1986 14:03 EST
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
There is no language-level interaction between catch and throw and
the lexical control mechanisms. To someone who understands lexical
scoping, RETURN and GO do "what one might expect." The tag or block
referred to is the one lexically apparent at the point of the GO or
RETURN.
People more familiar with dynamic scoping "may be surprised",
since the lexically apparent tag or block is not necessarly the
dynamically innermost one.
GO and RETURN sometimes need to remove crap from the stack in most
implementations. This may involve undoing special bindings and
"breaking up catchers." This is a feature of the implementation, not
the language.
No, "breaking up catchers" is a feature of the language, because a
lexical GO has to get back to the lexical environment of the target tag,
which may be outside the dynamic extent of some CATCH form.
∂15-Apr-86 1659 RAM@C.CS.CMU.EDU block/tagbody and catch/throw
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Apr 86 16:59:05 PST
Received: ID <RAM@C.CS.CMU.EDU>; Tue 15 Apr 86 19:59:41-EST
Date: Tue, 15 Apr 1986 19:59 EST
Message-ID: <RAM.12199144017.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: "David C. Plummer" <DCP@SCRC-QUABBIN.ARPA>
Cc: common-lisp@SU-AI.ARPA, SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: block/tagbody and catch/throw
In-reply-to: Msg of Tue 15 Apr 86 15:22 EST from David C. Plummer <DCP at SCRC-QUABBIN.ARPA>
Date: Tue, 15 Apr 86 15:22 EST
From: David C. Plummer <DCP at SCRC-QUABBIN.ARPA>
To: SANDRA <LOOSEMORE at UTAH-20.ARPA>, Rob MacLachlan <RAM>,
common-lisp at SU-AI.ARPA
Re: block/tagbody and catch/throw
Date: Tue 15 Apr 86 11:28:18-MST
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Am I the only person who finds the descriptions of the
interaction between block/tagbody and catch/throw in CLtL
confusing? On both pages 120 and 131, it's mentioned that the
lexical scoping of the block/tag names "has consequences that
may be suprising to users". What are these consequences?
Date: Tue, 15 Apr 1986 14:03 EST
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
GO and RETURN sometimes need to remove crap from the stack in most
implementations. This may involve undoing special bindings and
"breaking up catchers." This is a feature of the implementation, not
the language.
No, "breaking up catchers" is a feature of the language, because a
lexical GO has to get back to the lexical environment of the target tag,
which may be outside the dynamic extent of some CATCH form.
I think that the two examples referred to create more confusion than
they eliminate. It is a feature of the language that GO or RETURN can
change the dynamic environment. It is obvious from the scope rules
that the block or tag is not within the catch, therefore when control
is transferred to the block or tag, the catch is no longer in the
dynamic environment. How the catch disappears is an implementation
detail. It does make some sense to say that these code fragments are
legal, but discussion about the implementation is inappropriate in the
main text; it only confuses people.
I have a feeling that these features are much more surprising to
implementors than to users. It may not be obvious that a particular
combination is legal, but it should be fairly obvious what it does as
long as you haven't been damaged too much by Lisps with bizzare scope
rules.
Rob
∂16-Apr-86 0808 LOOSEMORE@UTAH-20.ARPA Re: block/tagbody and catch/throw
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 16 Apr 86 08:08:03 PST
Date: Wed 16 Apr 86 09:09:23-MST
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: Re: block/tagbody and catch/throw
To: RAM@C.CS.CMU.EDU
cc: DCP@SCRC-QUABBIN.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <RAM.12199144017.BABYL@C.CS.CMU.EDU>
Message-ID: <12199309654.18.LOOSEMORE@UTAH-20.ARPA>
Date: Tue, 15 Apr 1986 19:59 EST
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
I think that the two examples referred to create more confusion than
they eliminate. It is a feature of the language that GO or RETURN can
change the dynamic environment. It is obvious from the scope rules
that the block or tag is not within the catch, therefore when control
is transferred to the block or tag, the catch is no longer in the
dynamic environment. How the catch disappears is an implementation
detail. It does make some sense to say that these code fragments are
legal, but discussion about the implementation is inappropriate in the
main text; it only confuses people.
I have a feeling that these features are much more surprising to
implementors than to users.
My thoughts exactly. It should be sufficient to say that the return-from
(or go) can appear anywhere within the lexical scope of the block (or
tagbody). The current wording about "surprising consequences" is so vague
that non-wizardly readers can easily be mislead into thinking the behavior
is much more mysterious than that. It should be made clear that the
business of breaking up catchers is something that the implementor, not the
user, needs to think about.
-Sandra
-------
∂16-Apr-86 1325 hpfclp!paul@hplabs.ARPA
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 16 Apr 86 13:25:27 PST
Received: by hplabs.ARPA ; Wed, 16 Apr 86 12:51:09 pst
Date: Wed, 16 Apr 86 12:51:09 pst
From: hpfclp!paul@hplabs.ARPA
To: common-lisp@SU-AI.ARPA
Question: Should the floating point constants on pgs. 231-232 of CLtL
really be constants?
Here is an example. Take the constant double-float-epsilon. Suppose it
is derived on a system in which doubles are IEEE 64 bit format, and in
which the rounding precision is round to double. Fine.
Now suppose we want to use an MC68881, and we want to use the default
rounding precision (round to extended) because it is faster and gives
"better" results.
The problem is that double-float-epsilon, a constant is now incorrect;
i.e. it will not satisfy the criteria on pg 232. Basically the reason
is that when using the extended precision mode of the 881, a double
round error takes place (rounding the extended precison result to
extended precision and then rounding that to a double). In the
software, however, only one rounding takes place.
Hence, any code compiled on a system in which the floating point
constants are folded in-line will fail on 881 systems because the
constants no longer satisfy whatever their criteria was.
What to do? I see 2 viable solutions:
1). Put the 881 in the same rounding precision as the software.
2). Make the floating point constants variables. This has some
precedence; look at float-base, float-digits, and float-precision.
This problem could manifest itself in other instances - for example,
optional floating point accelerators in which the numeric format and/or
range is different from the host system's. How will that be handled?
Comments?
Paul Beiser
Hewlett-Packard
Ft. Collins, Colorado
uucp: ...{ihnp4!hpfcla,hplabs}!hpfclp!paul
arpa: paul%hpfclp@hplabs
∂16-Apr-86 1652 somewhere!hagiya@kurims.kurims.kyoto-u.junet
Received: from SU-SHASTA.ARPA by SU-AI.ARPA with TCP; 16 Apr 86 16:52:40 PST
Received: by su-shasta.arpa with TCP; Wed, 16 Apr 86 16:52:32 pst
Received: by ntt.junet (4.12/4.7JC-7) CHAOS with CHAOS-MAIL
id AA18711; Wed, 16 Apr 86 09:08:16 jst
From: hagiya@kurims.kurims.kyoto-u.junet
Received: by ntt.junet (4.12/4.7JC-7) CHAOS with CHAOS-MAIL
id AA18442; Wed, 16 Apr 86 09:02:50 jst
Received: by kurims.kyoto-u.junet (2.0/4.7)
id AA00595; Tue, 15 Apr 86 17:08:02 pst
Date: Tue, 15 Apr 86 17:08:02 pst
Message-Id: <8604160108.AA00595@kurims.kyoto-u.junet>
To: COMMON-LISP@SU-AI.ARPA
Hi, my name is Masami Hagiya, one of the implementors
of a Common Lisp system called KCL (Kyoto Common Lisp).
This is a kind of test mail to the Common Lisp mailing list
from the UNIX network in Japan, called JUNET. Unfortunately,
we don't have direct access to ARPA now.
There are many people in Japan who are interested in the
development of Common Lisp. For example, in last June,
we had a panel discussion on Common Lisp in Information
Processing Society of Japan, whose panelists were:
Ikuo Takeuchi (NTT)
Masayuki Ida (Aoyama-Gakuin Univ.)
Michiaki Yasumura (Hitachi)
Motoaki Terashima (Denki-Tsushi Univ.)
Taiichi Yuasa (Kyoto Univ.)
There are also several companies in Japan actually implementing
Common Lisp; I don't know whether I can make their names public
(oops, you can see two names above).
Our Common Lisp system, KCL, is not an evolutional one; our
major concern was
* faithfulness to CLtL
* portability
* compactness and simplicity
rather than the efficiency or the sophisticated debugging system.
The system seems quite comfortable now; it's as efficient
as other systems (or, at least, comparable; please look at the
benchmarks) and although we've implemented all the functions
in CLtL, the system is very small (e.g. KCL/SUN takes only about
1.7 mega). The most interesting thing is that since the system
is written in C and the compiler is a Lisp-to-C translator,
we can port the system to almost any UNIX (-like) machine.
In fact, KCL now runs on many machines including VAX/4.2BSD,
SUN2, SUN3, 3B2, MV/AOSVS, Apollo.
Articles to the Common Lisp mailing list are now distributed
in Japan via SHASTA-NTTLAB. Thank you.
Masami Hagiya
∂16-Apr-86 1911 DSinger@SRI-KL.ARPA Integer Shift Function(s)
Received: from SRI-KL.ARPA by SU-AI.ARPA with TCP; 16 Apr 86 18:40:35 PST
Date: Wed 16 Apr 86 15:42:31-PST
From: David Singer <DSinger@SRI-KL>
Subject: Integer Shift Function(s)
To: common-lisp%SU-AI@SRI-KL
I was translating an Interlisp program into Common Lisp and found that
Common Lisp has only arithmetic shift (ash, page 224), and unlike many
systems which have shift functions, no logical shift. Is this an
oversight, or a deliberate omission? Certainly it's possible to make
an lsh function, but taking care of word length etc. is painful and it
would (probably) not be as fast as a 'built-in'. (I note that the
Symbolics Common Lisp system and Lucid on Sun both provide lsh, but
Kyoto on Sun do not ... these are all the Common Lisp systems I have access
to).
Sorry if this question has previously been raised and answered, or if I
have missed something.
Dave Singer (dsinger@sri-kl)
-------
∂16-Apr-86 1930 FAHLMAN@C.CS.CMU.EDU Integer Shift Function(s)
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 16 Apr 86 19:28:16 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 16 Apr 86 22:29:00-EST
Date: Wed, 16 Apr 1986 22:28 EST
Message-ID: <FAHLMAN.12199433363.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: David Singer <DSinger@SRI-KL.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Integer Shift Function(s)
In-reply-to: Msg of 16 Apr 1986 18:42-EST from David Singer <DSinger at SRI-KL>
All of the logical operations are defined in terms of an abstract
integer type that is infinitely sign-extended to the left. That way,
the machine's word-length, or the length of the data part of its fixnum
representation, is hidden. What would a logical shift operation (or a
rotate, though you don't ask about that) do in this context?
An implementation may want to define LSH and ROT operations for its own
peculiar fixnum length, but such a thing makes no sense in portable
code.
-- Scott
∂16-Apr-86 2107 DT50@A.CS.CMU.EDU extending defstruct
Received: from A.CS.CMU.EDU by SU-AI.ARPA with TCP; 16 Apr 86 20:54:22 PST
Date: 16 Apr 86 23:55 EST
From: Dave.Touretzky@A.CS.CMU.EDU
To: common-lisp@SU-AI.ARPA
Subject: extending defstruct
I want to modify my suggestion for the syntax of byte fields in defstruct in
response to David Plummer's note. First, in order to be compatible with
existing CLtL syntax (as opposed to Zetalisp), the first element of the slot
description should be a *list* of byte field descriptions; thus we follow
the convention that the car of a slot descriptor names the slot(s), and the
cdr contains default values and options. Second, there is no need for a
:byte-field keyword, since the shape of every byte field *must* be specified.
So I propose the following:
(defstruct thingie
(foo 'default-foo-value)
(((low-bar nil (byte 8 0))
(mid-bar #x00 (byte 8 8) :read-only t)
(high-bar #x1a (byte 8 16)))
(baz 'default-baz-value))
Some notes: (1) A slot that is divided up into byte fields should be
restricted to type fixnum unless the user explicitly specifies that it
should be a bignum (or something else) via the :type keyword. So byte
specifiers that exceed the dimensions of a fixnum (or whatever type is
specified) should generate an error. (2) the list of byte field descriptors
may also contain as its first element a symbol, in which case the symbol is
taken to be the name of the entire slot. (3) Per Plummer's suggestion, a
default value of NIL for a byte field means ``no default.'' (4) If the user
specifies incompatible defaults for overlapping byte fields, an error
should be generated. (5) If overlapping byte fields are both filled by a
constructor, or if one is filled by a default and the other by a
constructor, the results of the operation are undefined.
Here's another example:
(defstruct gadget
(common-name nil)
((feature-bits
(input-size nil (byte 3 0))
(output-size nil (byte 3 3) :read-only t)
(clock-pins nil (byte 2 6))
(internal-store nil (byte 10 8)))
#x12345 :type fixnum)
(gadget-cost :type short-float))
The slot GADGET-FEATURE-BITS is of type fixnum and is divided into four
byte fields. Note that in this example we gave the entire slot a default
value rather than giving the byte fields separate defaults.
-- Dave
∂17-Apr-86 0620 KMP@SCRC-STONY-BROOK.ARPA (PROCLAIM '(IGNORE ...))
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 17 Apr 86 06:20:03 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 465565; Wed 16-Apr-86 22:20:09-EST
Date: Wed, 16 Apr 86 22:20 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: (PROCLAIM '(IGNORE ...))
To: Common-Lisp@SU-AI.ARPA
Message-ID: <860416222044.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I know some implementations don't have the "feature" that the variable IGNORE
implicitly declared IGNORE by the compiler. My question is, can I do:
(PROCLAIM '(IGNORE IGNORE IGNORED IGNORABLE DONT-CARE HUNOZ ...))
to teach those implementations? My reading of CLtL (p160) is that I should
be able to. Does anyone disagree?
∂17-Apr-86 0702 greek%bach.decnet@hudson.dec.com (PROCLAIM '(IGNORE ...))
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 17 Apr 86 07:01:02 PST
Date: 17 Apr 86 09:41:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: (PROCLAIM '(IGNORE ...))
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
The book says that the IGNORE declaration affects only variable bindings.
I think this is trying to say that you can't proclaim an ignore.
Is it really that hard to put the appropriate declarations in the
(hopefully) few places where you want to ignore something?
- Paul
------
∂17-Apr-86 0810 marchett%cod@nosc.ARPA slotp
Received: from NOSC.ARPA by SU-AI.ARPA with TCP; 17 Apr 86 08:07:09 PST
Received: by bass.ARPA (5.31/4.7)
id AA01935; Thu, 17 Apr 86 08:08:17 PST
Received: by cod.ARPA (5.31/4.7)
id AA25949; Thu, 17 Apr 86 08:08:14 PST
Date: Thu, 17 Apr 86 08:08:14 PST
From: David J. Marchette <marchett%cod@nosc.ARPA>
Message-Id: <8604171608.AA25949@cod.ARPA>
To: common-lisp@su-ai
Subject: slotp
Is there an easy way to tell if an instance variable (or slot) is
available in a particular structure? Given an instance of a structure,
I'd like an easy way to tell if location is one of its instance variables
(or slots). One way would be to inspect the plist of the instances
structure: (I don't have a machine available at the moment, but you
get the idea)
(member 'location (symbol-plist (type-of foobar)))
...or whatever. Is there an easier way, assuming that something like
the above would even work? I think something like it would work on the
Symbolics, but I don't know if it would be portable. A predefined function
slotp would be nice, but such does not seem to be available.
Thanks for any help.
dave
***********************************
* David Marchette *
* *
* marchett@cod.UUCP *
* marchett@noscvax.UUCP *
* marchett@cod.nosc.MIL *
* ucbvax!sdcsvax!noscvax!marchett *
* *
* Naval Ocean Systems Center *
* Code 421 *
* 271 Catalina Blvd. *
* San Diego, CA 92152 *
* *
* Ph. (619) 225-6571 *
***********************************
∂17-Apr-86 0927 @SRI-KL.ARPA:gls@AQUINAS.THINK.COM Integer Shift Function(s)
Received: from SRI-KL.ARPA by SU-AI.ARPA with TCP; 17 Apr 86 09:25:37 PST
Received: from GODOT.THINK.COM by SRI-KL.ARPA with TCP; Thu 17 Apr 86 09:26:25-PST
Received: from sebastian by GODOT.THINK.COM via CHAOS; Thu, 17 Apr 86 12:26:01 est
Date: Thu, 17 Apr 86 12:27 EST
From: Guy Steele <gls@AQUINAS.THINK.COM>
Subject: Integer Shift Function(s)
To: DSinger@SRI-KL, common-lisp%SU-AI@SRI-KL
Cc: gls@AQUINAS
In-Reply-To: <8604170313.AA00311@GODOT.THINK.COM>
Message-Id: <860417122722.1.GLS@THINK-SEBASTIAN.ARPA>
Date: Wed 16 Apr 86 15:42:31-PST
From: David Singer <DSinger@SRI-KL>
I was translating an Interlisp program into Common Lisp and found that
Common Lisp has only arithmetic shift (ash, page 224), and unlike many
systems which have shift functions, no logical shift. Is this an
oversight, or a deliberate omission? Certainly it's possible to make
an lsh function, but taking care of word length etc. is painful and it
would (probably) not be as fast as a 'built-in'. (I note that the
Symbolics Common Lisp system and Lucid on Sun both provide lsh, but
Kyoto on Sun do not ... these are all the Common Lisp systems I have access
to).
Sorry if this question has previously been raised and answered, or if I
have missed something.
Dave Singer (dsinger@sri-kl)
-------
This was deliberate omission, for essentially the reasons you cite of
pain and portability. Note that LDB can handle many of the purposes
of LSH.
--Guy
∂17-Apr-86 1122 DCP@ALLEGHENY.SCRC.Symbolics.COM Integer Shift Function(s)
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 17 Apr 86 11:22:46 PST
Received: from FIREBIRD.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 12613; Thu 17-Apr-86 12:29:29-EST
Date: Thu, 17 Apr 86 12:26 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: Integer Shift Function(s)
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>,
David Singer <DSinger@SRI-KL.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12199433363.BABYL@C.CS.CMU.EDU>
Message-ID: <860417122623.2.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Wed, 16 Apr 1986 22:28 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
[This looks like a reply.]
All of the logical operations are defined in terms of an abstract
integer type that is infinitely sign-extended to the left. That way,
the machine's word-length, or the length of the data part of its fixnum
representation, is hidden. What would a logical shift operation (or a
rotate, though you don't ask about that) do in this context?
I agree, it can't do anything.
An implementation may want to define LSH and ROT operations for its own
peculiar fixnum length, but such a thing makes no sense in portable
code.
JonL, at one point, suggested abstract LSH and ROT operations that take
a third argument which is the pretend-I'm-a-fixnum-length. Thus,
(rot 1 -1 5) == (ash -1 4) == -16.
(lsh -1 -1 6) == #2r011111 == 31.
Personally, I think this is cute, but probably not extrememly practical.
Also note: I think you will find most uses of LSH and ROT (for those
extended Common Lisps that implement them) are almost exclusively inside
operating system code.
∂17-Apr-86 1123 DCP@ALLEGHENY.SCRC.Symbolics.COM extending defstruct
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 17 Apr 86 11:23:22 PST
Received: from FIREBIRD.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 12617; Thu 17-Apr-86 12:44:09-EST
Date: Thu, 17 Apr 86 12:41 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: extending defstruct
To: Dave.Touretzky@A.CS.CMU.EDU, common-lisp@SU-AI.ARPA
In-Reply-To: The message of 16 Apr 86 23:55 EST from Dave.Touretzky@A.CS.CMU.EDU
Message-ID: <860417124125.3.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: 16 Apr 86 23:55 EST
From: Dave.Touretzky@A.CS.CMU.EDU
I want to modify my suggestion for the syntax of byte fields in defstruct in
response to David Plummer's note. First, in order to be compatible with
existing CLtL syntax (as opposed to Zetalisp), the first element of the slot
description should be a *list* of byte field descriptions; thus we follow
the convention that the car of a slot descriptor names the slot(s), and the
cdr contains default values and options. Second, there is no need for a
:byte-field keyword, since the shape of every byte field *must* be specified.
Even so, I think the :byte-field keyword should be there for
consistency. There's another reason: consider the possibility of
boolean fields (NIL/T instead of 0/1). This could look like
:boolean-field instead of :byte-field. There is no reason why bytes and
booleans can't be mixed. Also, there is no hard reason why a boolean
field need be 1 bit wide. (This assumes any 1 is truth, and that
setting to truth sets all bits.) Also, the shape of every byte field
does NOT need to be specified. Consider
(defstruct thingie
(foo 'default-foo-value)
((whole-second-slot 0 :type fixnum)
(low-bar nil (byte 8 0))
(mid-bar #x00 (byte 8 8) :read-only t)
(high-bar #x1a (byte 8 16)))
(baz 'default-baz-value))
This is a natural place to declare the whole-second-slot to be of type
fixnum.
So I propose the following:
(defstruct thingie
(foo 'default-foo-value)
((low-bar nil (byte 8 0))
(mid-bar #x00 (byte 8 8) :read-only t)
(high-bar #x1a (byte 8 16)))
(baz 'default-baz-value))
Some notes: (1) A slot that is divided up into byte fields should be
restricted to type fixnum unless the user explicitly specifies that it
should be a bignum (or something else) via the :type keyword. So byte
specifiers that exceed the dimensions of a fixnum (or whatever type is
specified) should generate an error.
I disagree with this because it can lead to non-portable code, that is,
it depends on the size of fixnums. I think the default should be
integer and the user must explicitly state fixnum. As stated above, the
:TYPE keyword could be awkward in the individual bytes and is better
placed in the whole slot descriptor.
(2) the list of byte field descriptors
may also contain as its first element a symbol, in which case the symbol is
taken to be the name of the entire slot.
I'm confused. Maybe that's why you had an extra (, for a total of
three, before low-bar? I think there is too much symmetry being broken.
(3) Per Plummer's suggestion, a
default value of NIL for a byte field means ``no default.'' (4) If the user
specifies incompatible defaults for overlapping byte fields, an error
should be generated. (5) If overlapping byte fields are both filled by a
constructor, or if one is filled by a default and the other by a
constructor, the results of the operation are undefined.
Here's another example:
(defstruct gadget
(common-name nil)
((feature-bits
(input-size nil (byte 3 0))
(output-size nil (byte 3 3) :read-only t)
(clock-pins nil (byte 2 6))
(internal-store nil (byte 10 8)))
#x12345 :type fixnum)
(gadget-cost :type short-float))
[Gadget-cost default??]
The slot GADGET-FEATURE-BITS is of type fixnum and is divided into four
byte fields. Note that in this example we gave the entire slot a default
value rather than giving the byte fields separate defaults.
For comparison, this is how it would look in my proposed scheme, with
some more things that use the boolean-field feature.
(defstruct gadget
(common-name nil)
((feature-bits #x12345 :type fixnum)
(input-size nil :byte-field (byte 3 0))
(output-size nil :byte-field (byte 3 3) :read-only t)
(clock-pins nil :byte-field (byte 2 6))
(internal-store nil :byte-field (byte 10 8))
(something-on-p nil :boolean-field (byte 3 18))
(foo-on nil :boolean-field (byte 1 18))
(bar-on nil :boolean-field (byte 1 19))
(baz-on nil :boolean-field (byte 1 20)))
(gadget-cost 0.0 :type short-float))
∂17-Apr-86 1434 Gregor.pa@Xerox.COM What is a compiler (vol. 63827) meets what are gensyms.
Received: from XEROX.COM by SU-AI.ARPA with TCP; 17 Apr 86 14:32:32 PST
Received: from Semillon.ms by ArpaGateway.ms ; 17 APR 86 14:19:29 PST
Date: Thu, 17 Apr 86 14:15 PST
From: Gregor.pa@Xerox.COM
Subject: What is a compiler (vol. 63827) meets what are gensyms.
To: Common-Lisp@SU-AI.arpa
cc: Gregor.pa@Xerox.COM
Message-ID: <860417141538.0.GREGOR@AVALON.XEROX-PARC>
Line-fold: no
In this issue the subject of what compile file is required to do with
top-level forms meets the subject of top-level calls to macros which
expand into code containing gensyms.
Suppose I have the following macro.
(defmacro foo (x y)
(let ((var (gensym))
(nv-var (gensym)))
`(progn
(defun ,x ..)
(defun ,y ..)
(defsetf ,x (,var) (,nv-var) `(,',y ,,var ,,nv-var)))))
And I have a file that includes the form:
(FOO BAR SET-BAR)
[ For clarities sake, the point is that the macro expands
to a progn that includes a defsetf that has gensyms for
the access-function-args and storing-variables, like this:
(DEFSETF BAR (#:G1890) (#:G1891) `(SET-BAR ,#:G1890 ,#:G1891))
]
Is compiling and loading the file legal Common Lisp?
Is the original foo macro legal Common Lisp?
I claim that the answer to both questions is yes. After all, it is
clearly legal interpreted/compiled to core Common Lisp.
I believe that CLtL is "silent" on this issue.
I got bit by a Common Lisp compiler which macroexpands top-level forms,
but which does not necessarily compile the entire result of the
macroexpansion. In this particular case the compiler expanded the two
defuns, but left the defsetf as (store-setf '<list with gensyms in it>)
Then the dumper dumped that list in such a way that when the file was
loaded the gensyms which should have been eq were not.
-------
∂17-Apr-86 1610 DT50@A.CS.CMU.EDU Plummer wins
Received: from A.CS.CMU.EDU by SU-AI.ARPA with TCP; 17 Apr 86 16:09:50 PST
Date: 17 Apr 86 18:51 EST
From: Dave.Touretzky@A.CS.CMU.EDU
To: common-lisp@SU-AI.ARPA
Subject: Plummer wins
I like Plummer's revised proposal (including boolean fields) better than my
revised proposal. Nobody else has said anything on the issue.
So now what happens? That is, what does it take to get this feature
added to the next revision of the Common Lisp standard?
-- Dave
∂18-Apr-86 0648 FAHLMAN@C.CS.CMU.EDU What is a compiler (vol. 63827) meets what are gensyms.
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 18 Apr 86 06:48:34 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 18 Apr 86 09:50:10-EST
Date: Fri, 18 Apr 1986 09:50 EST
Message-ID: <FAHLMAN.12199819510.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Gregor.pa@XEROX.COM
Cc: Common-Lisp@SU-AI.ARPA
Subject: What is a compiler (vol. 63827) meets what are gensyms.
In-reply-to: Msg of 17 Apr 1986 17:15-EST from Gregor.pa at Xerox.COM
Unless I'm missing soemthing very subtle, I think that your example is
legal Common Lisp. I don't think the current manual actually forces you
to compile that Defsetf, but whether or not it is compiled, the dumper
has no business losing track of the EQ-ness of the symbols, whether or
not they are interned anywhere.
-- Scott
∂18-Apr-86 0911 RAM@C.CS.CMU.EDU Plummer wins
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 18 Apr 86 09:11:13 PST
Received: ID <RAM@C.CS.CMU.EDU>; Fri 18 Apr 86 12:13:34-EST
Date: Fri, 18 Apr 1986 12:13 EST
Message-ID: <RAM.12199845608.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: Dave.Touretzky@A.CS.CMU.EDU
Cc: common-lisp@SU-AI.ARPA
Subject: Plummer wins
In-reply-to: Msg of 17 Apr 1986 18:51-EST from Dave.Touretzky at A.CS.CMU.EDU
Well, I haven't said anything yet because I was hoping that this
discussion would die without any help. I strongly believe that
nothing even remotely resembling bit-fields should be a part of Common
Lisp. There seem to be two general kinds of uses for this thing:
1] External interfaces in which the exact bit layout must be specified.
2] Compact representation of structures containing small integers.
The bit-field mechanism is more oriented to systems hacking, in that
it allows the exact layout of bits to be specified. This is necessary
for systems hacking but is totally unnecessary for the second class of
uses. This exact-layout provision is also the cause of portability
problems with respect to fixnum size.
It seems pretty clear that the only portable programs that could use
bit-fields would use it simply to get compact record structures. As
people have observed, nothing prevents the current defstruct from
representing fields compactly, at least in the named case.
The only other justification for putting bit-fields in Common Lisp is
that it is so obviously useful for systems hacking that we might as
well standardize it. I strongly disagree with this view. At one time
we had a mechanism similar to defstruct with bit-fields; although it
was more general than what is proposed, we found it totally inadequate
for specifying our external interfaces.
It might be worth adding a :optimize defstruct keyword which could be
used to specifiy whether the representation should be optimized for
speed or space. It might also be worth relaxing the defstruct
specification so that even typed structures could have packed fields.
Rob
∂18-Apr-86 0939 greek%bach.decnet@hudson.dec.com Bit fields in structures.
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 18 Apr 86 09:39:26 PST
Date: 18 Apr 86 12:26:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: Bit fields in structures.
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
I agree with Rob that we should stay away from this issue. In particular,
if people want features for interfacing with alien languages, then
Common LISP should include an alien structure and alien routine facility,
separate from the rest of the language. I think this for two reasons.
1. There are a lot of features needed to adequately support alien
languages, and we ought to put them in one place instead of
sprinkling them around the language.
2. We could all too easily invent features that some implementations
couldn't handle. This is less likely if there is one facility,
carefully designed, with hooks for additional system-dependent
goodies.
- Paul
------
∂18-Apr-86 1324 NGALL@G.BBN.COM Type Specifier: (OR (FUNCTION ...) ...)
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 18 Apr 86 13:24:09 PST
Date: 18 Apr 1986 16:07-EST
Sender: NGALL@G.BBN.COM
Subject: Type Specifier: (OR (FUNCTION ...) ...)
From: NGALL@G.BBN.COM
To: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]18-Apr-86 16:07:14.NGALL>
Question: What is the 'most informative' type specifier for
the CL function COPY-SEQ?
How 'bout?
(function (sequence) sequence)
Unfortunately, this does not tell the reader nor the compiler that if
the argument is a list, then the result is also a list, and vice
versa. So how about this:
(or (function (list) list)
(function (vector) vector))
This is syntactically valid CL, and the definition of the OR and
FUNCTION type specifiers makes it meaningful. Unfortunately, it is
not clear from pg. 158 whether or not the following is legal:
(proclaim '(ftype (or (function (list) list)
(function (vector) vector))
copy-seq))
It is not legal in VaxLisp, and my guess is that there aren't any
implementations that would do the right thing with it. So I would like
to propose that such a use of OR/FUNCTION be considered legal CL.
Without such a declaration, one is forced to either wrap
(the <result-type> ...) around all calls to such functions or to
DECLARE a restricted version of FUNCTION in the appropriate places,
e.g.,
(defun foo (alist avector)
(declare (list alist)
(vector avector)
(function copy-seq (list) list))
(zap (copy-seq alist)
(let ()
(declare (function copy-seq (vector) vector))
(zoop (copy-seq avector))))
Either method is a real pain.
This use of OR would give CL something akin to Ada overloading. It
allows the overloading of multiple 'function type signatures' on a
single function name. Such overloading is already implicit throughout
CL (esp. the seq. functions). My proposal would merely allow a way of
describing it.
-- Nick
∂18-Apr-86 1946 KMP@SCRC-STONY-BROOK.ARPA slotp
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 18 Apr 86 19:46:32 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 466458; Thu 17-Apr-86 23:56:29-EST
Date: Thu, 17 Apr 86 23:57 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: slotp
To: marchett%cod@NOSC.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <8604171608.AA25949@cod.ARPA>
Message-ID: <860417235708.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Thu, 17 Apr 86 08:08:14 PST
From: David J. Marchette <marchett%cod@nosc.ARPA>
Is there an easy way to tell if an instance variable (or slot) is available
in a particular structure?
What good would it do to have a SLOTP predicate? What operation can you do
on a structure once you know it has such a slot? The point is that you're
not supposed to go around looking for slots by name except maybe in a debugger,
and debuggers are intended to be provided in an implementation-dependent fashion
by each system.
It's a data-abstraction violation to know what a structure calls its slot names.
If you're supposed to be poking about in the structure, the person who authorized
you to do so will have given you the following information: a symbol which can
be used as a second argument to TYPEP to tell if you have one of the structures
in question, a function which creates such structures and/or a set of functions
which will access their slots, and documentation on how to use those accessors
correctly.
∂18-Apr-86 1959 Moon@SAPSUCKER.SCRC.Symbolics.COM Should the floating-point constants really be constants?
Received: from [192.10.41.223] by SU-AI.ARPA with TCP; 18 Apr 86 19:59:10 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 9243; Fri 18-Apr-86 17:31:13 EST
Date: Fri, 18 Apr 86 17:30 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Should the floating-point constants really be constants?
To: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 16 Apr 86 15:51 EST from hpfclp!paul@hplabs.ARPA
Message-ID: <860418173043.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 16 Apr 86 12:51:09 pst
From: hpfclp!paul@hplabs.ARPA
Question: Should the floating point constants on pgs. 231-232 of CLtL
really be constants?
Here is an example. Take the constant double-float-epsilon. Suppose it
is derived on a system in which doubles are IEEE 64 bit format, and in
which the rounding precision is round to double. Fine.
Now suppose we want to use an MC68881, and we want to use the default
rounding precision (round to extended) because it is faster and gives
"better" results.
The problem is that double-float-epsilon, a constant is now incorrect;
i.e. it will not satisfy the criteria on pg 232. Basically the reason
is that when using the extended precision mode of the 881, a double
round error takes place (rounding the extended precison result to
extended precision and then rounding that to a double). In the
software, however, only one rounding takes place.
Doesn't this only show that this particular method of implementing floating
point has a bug in it? You can either live with the bug or not use this
method of implementing floating point, whichever you judge is best.
Hence, any code compiled on a system in which the floating point
constants are folded in-line will fail on 881 systems because the
constants no longer satisfy whatever their criteria was.
This problem could manifest itself in other instances - for example,
optional floating point accelerators in which the numeric format and/or
range is different from the host system's. How will that be handled?
This I think is a different issue, and a more interesting one. Let me
rephrase what I think you are saying: Suppose I have two Lisp systems that are
so close to each other that compiled code from one can be loaded into the
other. The only difference between them is that they use different
floating-point formats. Should the Common Lisp language be changed to allow
me to call these two Lisp systems one Lisp system that from time to time
changes its floating-point format, by changing these constants to variables?
My reaction is that I'm uncomfortable with changing the definition of the
language to provide such a specialized feature (compiled code portability
between two similar implementations). Perhaps there is another solution that
doesn't involve changing the language. One obvious candidate is this: if you
have two different floating-point formats, don't call them by the same name.
Perhaps you can call one of them double and the other one long. If the total
number of formats is more than four, introduce some more floating-point types
(the manual pp.33-5 appears to allow this.)
∂18-Apr-86 2011 KMP@SCRC-STONY-BROOK.ARPA (PROCLAIM '(IGNORE ...))
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 18 Apr 86 20:11:40 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 466463; Fri 18-Apr-86 00:49:38-EST
Date: Fri, 18 Apr 86 00:50 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: (PROCLAIM '(IGNORE ...))
To: greek%bach.decnet@hudson.dec.com
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 17 Apr 86 09:41-EST from "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
References: <860416222044.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <860418005011.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 17 Apr 86 09:41:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
The book says that the IGNORE declaration affects only variable bindings.
I think this is trying to say that you can't proclaim an ignore.
I dunno. The wording is kinda fuzzy if you ask me.
Is it really that hard to put the appropriate declarations in the
(hopefully) few places where you want to ignore something?
Yes, it is somewhat of a hassle because it does occur a lot. Macsyma, for
example, has a couple hundred functions which either ignore some argument
or which MULTIPLE-VALUE-BIND for a set of quantities, some of which will
need to be ignored. Writing the IGNORE declaration wastes lots of screen
space and sometimes makes just enough difference to make it impossible to
see an entire definition on one screen. (I didn't write those definitions
so please no lectures about how such functions are too long; I agree, but
it's not always so easy a thing to fix and I have more important things to
be doing with my time anyway.)
The places where I find the use of an IGNORE variable especially attractive
are things like:
(MAPCAR #'(LAMBDA (IGNORE) (GENSYM)) THINGS)
This is short and to-the-point. Having to write:
(MAPCAR #'(LAMBDA (THING) (DECLARE (IGNORE THING)) (GENSYM)) THINGS)
makes the form wide enough and cluttered enough that it starts to be hard
to read. Also, as a point of style I like to break multi-statement LAMBDAs
onto multiple lines, and end up writing:
(MAPCAR #'(LAMBDA (THING)
(DECLARE (IGNORE THING))
(GENSYM))
THINGS)
which I find to be readable, but which unfortunately uses a ridiculous amount
of screen space to say something which should be much shorter and punchier.
Sometimes it makes sense to (DECLARE (IGNORE ...)). For example, I may do:
(DEFUN CURSOR-Y ()
(MULTIPLE-VALUE-BIND (X Y)
(CURSOR-POSITION)
(DECLARE (IGNORE X))
Y))
because it provides a kind of documentation in spite of its obvious waste of
vertical space. Plenty of my co-workers wouldn't dream of writing anything
other than this:
(DEFUN CURSOR-Y () (MULTIPLE-VALUE-BIND (IGNORE Y) (CURSOR-POSITION) Y))
In other situations, though, I may not know or care what the thing is that
I'm ignoring, so it's a pain to have to think up a name for the argument.
For example, sometimes I just want to do:
(DEFUN DRAW-LINE (&REST IGNORE)
(ERROR "I don't know how to draw a line."))
and I resent having to do:
(DEFUN DRAW-LINE (&REST WHATEVER)
(DECLARE (IGNORE WHATEVER))
(ERROR "I don't know how to draw a line."))
because I think it's visual clutter to no good end.
In fact, there is at least one family of functions in Macsyma which we've just
never gotten around to fixing which take three arguments, the middle of which
is always ignored. NIL is always passed as the actual argument, so there
is really no proper name for the incoming data, the true purpose is long-since
forgotten. Instead, the functions all look like:
(DEFUN FOO (X VESTIGIAL Y)
(DECLARE (IGNORE VESTIGIAL))
...)
but again I'd prefer to be doing just
(DEFUN FOO (X IGNORE Y)
...)
One of these days I'll get around to just changing the arg conventions and
updating all the callers, but in the meantime I find it distracting to waste
a screen line for a nonsensical declaration.
The real problem in my mind is that there is nothing in error about the
following code:
(LAMBDA (X Y) X)
There is really no reason for the compiler to be warning me about it.
This sort of thing used to be the bread and butter of the lambda calculus.
You'd never have been able to write a serious program without it. It's
quite well-formed. It has an obvious interpretation. Warnings about code
like this from modern compilers is presumably intended as a courtesy to
me because someone thinks it's unlikely that I would really want to do
this. There are certainly many possible good reasons for doing it, though.
As such, the thing that warns me should take reasonable steps to notice
any clues that I might have given that would suggest that I might not want
to be bothered about this. I suggest that
(LAMBDA (X IGNORE) X)
is about as blatant a clue as I can think of. Heck, I'm even willing to
write:
(PROCLAIM '(IGNORE IGNORE))
to make it doubly clear that when I really mean to ignore IGNORE. I'm not
asking for natural language parsing, after all. So here I am bending over
backward with a desire to tell compilers that it's OK to not warn me about
dozens of functions that weren't in error in the first place and some of
the compilers just aren't going to want to listen... Sigh.
∂18-Apr-86 2013 Moon@SCRC-STONY-BROOK.ARPA Should the floating-point constants really be constants?
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 18 Apr 86 20:12:45 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 467060; Fri 18-Apr-86 17:31:08-EST
Date: Fri, 18 Apr 86 17:30 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Should the floating-point constants really be constants?
To: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 16 Apr 86 15:51 EST from hpfclp!paul@hplabs.ARPA
Message-ID: <860418173043.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 16 Apr 86 12:51:09 pst
From: hpfclp!paul@hplabs.ARPA
Question: Should the floating point constants on pgs. 231-232 of CLtL
really be constants?
Here is an example. Take the constant double-float-epsilon. Suppose it
is derived on a system in which doubles are IEEE 64 bit format, and in
which the rounding precision is round to double. Fine.
Now suppose we want to use an MC68881, and we want to use the default
rounding precision (round to extended) because it is faster and gives
"better" results.
The problem is that double-float-epsilon, a constant is now incorrect;
i.e. it will not satisfy the criteria on pg 232. Basically the reason
is that when using the extended precision mode of the 881, a double
round error takes place (rounding the extended precison result to
extended precision and then rounding that to a double). In the
software, however, only one rounding takes place.
Doesn't this only show that this particular method of implementing floating
point has a bug in it? You can either live with the bug or not use this
method of implementing floating point, whichever you judge is best.
Hence, any code compiled on a system in which the floating point
constants are folded in-line will fail on 881 systems because the
constants no longer satisfy whatever their criteria was.
This problem could manifest itself in other instances - for example,
optional floating point accelerators in which the numeric format and/or
range is different from the host system's. How will that be handled?
This I think is a different issue, and a more interesting one. Let me
rephrase what I think you are saying: Suppose I have two Lisp systems that are
so close to each other that compiled code from one can be loaded into the
other. The only difference between them is that they use different
floating-point formats. Should the Common Lisp language be changed to allow
me to call these two Lisp systems one Lisp system that from time to time
changes its floating-point format, by changing these constants to variables?
My reaction is that I'm uncomfortable with changing the definition of the
language to provide such a specialized feature (compiled code portability
between two similar implementations). Perhaps there is another solution that
doesn't involve changing the language. One obvious candidate is this: if you
have two different floating-point formats, don't call them by the same name.
Perhaps you can call one of them double and the other one long. If the total
number of formats is more than four, introduce some more floating-point types
(the manual pp.33-5 appears to allow this.)
∂19-Apr-86 0831 tansei!a37078%utokyo-relay.csnet@CSNET-RELAY.ARPA We are entering a new stage....
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 19 Apr 86 08:31:40 PST
Received: from utokyo-relay by csnet-relay.csnet id ac08654; 19 Apr 86 11:26 EST
Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA28200; Sat, 19 Apr 86 18:47:46+0900
Received: by tansei.u-tokyo.junet (4.12/4.9J)
id AA29674; Sat, 19 Apr 86 11:53:51+0900
Date: Sat, 19 Apr 86 11:53:51+0900
From: Masayuki Ida <tansei!a37078%utokyo-relay.csnet@CSNET-RELAY.ARPA>
Message-Id: <8604190253.AA29674@tansei.u-tokyo.junet>
To: common-lisp%su-ai.arpa@CSNET-RELAY.ARPA, ida@utokyo-relay.CSNET
Subject: We are entering a new stage....
We are entering a new stage in japan.
First,` it is my great pleasure to tell you all that we had have a firm link to USA.
Since this april, Utokyo-relay, which is also called as ccut, is now an offical node of CSNet,
with the efforts of many university professors.
This mail is directed through csnet.
With this link, I can communicate with many key members in USA more
conveniently than last year.
So, I am trying to communicate with arpa bboard.
Second, as the chair, I finished the first year of our commonlisp committee at jeida,
Japan Electronics Industries`Development Association, and now entering
the second year from this April.
Please don't missunderstand the committee I am talking of is closed against USA.
We have several members from subsidaries`of US companys,
such as xerox, symbolics, digital, data`general, univac.
I reported the existence of the committee to several key members of USA,
and at IJCAI'85 press conference.
I want to assist to grow up Common Lisp community in Japan.
We have a meeting once a month.
This year, we want to do the followings.
1) finish the subset spec discussions after one year efforts and compile a subset draft.
2) make a kanji standard`for`CommonLisp.
3)`try to contribute the object oriented discussions.
I will send`a report to this bboard periodically.
Thank you
Masayuki Ida (Assoc.Prof. Aoyama Gakuin University)
ida%utokyo-relay.csnet@csnet-relay.arpa
(ida is aliased to my registered code, A37078)
UUCP: ...!hplabs!kddlab!ccut!ida
...!Shasta!ntt!ccut!ida
(UUCP link over the pacific ocean may fail accidentally
by`non-techical`reasons)
∂19-Apr-86 1307 FAHLMAN@C.CS.CMU.EDU (PROCLAIM '(IGNORE ...))
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 19 Apr 86 13:05:18 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 19 Apr 86 16:07:29-EST
Date: Sat, 19 Apr 1986 16:07 EST
Message-ID: <FAHLMAN.12200150344.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: (PROCLAIM '(IGNORE ...))
In-reply-to: Msg of 18 Apr 1986 00:50-EST from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
Special treatment of IGNORE as a variable name was left out of the
language because a lot of people objected to having the language poke
holes in the namespace. (However, we relented with T, NIL, and the
various &... symbols.)
The lexically scoped IGNORE declaration seemed a much cleaner solution.
Allowing global IGNORE proclamations seems a bit unclean to me, since
it can have an effect on variables that come in from God-knows-where and
that were never intended to be ignored. On the other hand, this would
not be disastrous -- it would result in a few spurious compiler warnings
in a few odd cases, and it wouldn't be at all hard to see what went
wrong.
So I wouldn't object to a decision that (PROCLAIM '(IGNORE ...))
is legal.
-- Scott
∂19-Apr-86 1322 FAHLMAN@C.CS.CMU.EDU Type Specifier: (OR (FUNCTION ...) ...)
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 19 Apr 86 13:22:06 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 19 Apr 86 16:24:24-EST
Date: Sat, 19 Apr 1986 16:24 EST
Message-ID: <FAHLMAN.12200153421.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: NGALL@BBNG.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: Type Specifier: (OR (FUNCTION ...) ...)
In-reply-to: Msg of 18 Apr 1986 16:07-EST from NGALL at G.BBN.COM
Regarding your proposal that we allow forms like the following
(or (function (list) list)
(function (vector) vector))
as a way of specifying that the output type of a function matches its
input type...
It seems to me that there are a lot of things one might want to tell a
compiler about the type relationships between the arguments to a
function and its values. For example, + performed on a positive fixnum
and a negative one is sure to return a fixnum, so no bignum check is
required. Your proposal seems to take one small step in the direction
of such a declarative language, and then it stops. If it were clear
that the extra cases your mechanism handles are the most common and
important ones, then I'd favor adding this special case, but it isn't
clear to me. Also, it gets into all the issues raised by the
Commonloops type-precedence stuff. If someone were to say
(or (function (list sequence) foo)
(function (sequence list) bar))
then what do we do? Once the object-oriented stuff settles a bit, maybe
the answer will be clear.
-- Scott
∂19-Apr-86 1409 NGALL@G.BBN.COM Re: Type Specifier: (OR (FUNCTION ...) ...)
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 19 Apr 86 14:09:11 PST
Date: 19 Apr 1986 17:08-EST
Sender: NGALL@G.BBN.COM
Subject: Re: Type Specifier: (OR (FUNCTION ...) ...)
From: NGALL@G.BBN.COM
To: Fahlman@C.CS.CMU.EDU
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]19-Apr-86 17:08:16.NGALL>
In-Reply-To: <FAHLMAN.12200153421.BABYL@C.CS.CMU.EDU>
Date: Sat, 19 Apr 1986 16:24 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: NGALL@BBNG.ARPA
Subject: Type Specifier: (OR (FUNCTION ...) ...)
In-Reply-To: Msg of 18 Apr 1986 16:07-EST from NGALL at G.BBN.COM
Message-ID: <FAHLMAN.12200153421.BABYL@C.CS.CMU.EDU>
Regarding your proposal that we allow forms like the following
(or (function (list) list)
(function (vector) vector))
as a way of specifying that the output type of a function matches its
input type...
It seems to me that there are a lot of things one might want to tell a
compiler about the type relationships between the arguments to a
function and its values. For example, + performed on a positive fixnum
and a negative one is sure to return a fixnum, so no bignum check is
required.
Under my proposal, the above constraint could be declared as follows:
(proclaim '(ftype (or (function ((integer 0 #.most-positive-fixnum)
(integer #..most-negative-fixnum 0))
fixnum)
(function (&rest number) number))))
Of course, other constraints (e.g., + performed on integers results in
an integer) could be included also. One constraint that could not be
directly declared is that + performed on N rationals one of which is a
float results in a float. But since most compilers transform the
multi-argument versions of functions into equivalent nested two-arg
version, enumerating the two-arg type combinations would suffice.
Your proposal seems to take one small step in the direction
of such a declarative language, and then it stops.
Could you give me an example of the further steps you would like to see?
If it were clear
that the extra cases your mechanism handles are the most common and
important ones, then I'd favor adding this special case, but it isn't
clear to me. Also, it gets into all the issues raised by the
Commonloops type-precedence stuff. If someone were to say
(or (function (list sequence) foo)
(function (sequence list) bar))
then what do we do?
According to the definition of the OR type-spec on pg. 45, "it always
tests each of the component types in order from left to right and
stops procesing as soon as one component of the union has been found
to which the object belongs."
Once the object-oriented stuff settles a bit, maybe
the answer will be clear.
-- Scott
--------------------
-- Nick
∂19-Apr-86 1440 NGALL@G.BBN.COM Re: (PROCLAIM '(IGNORE ...))
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 19 Apr 86 14:38:21 PST
Date: 19 Apr 1986 17:36-EST
Sender: NGALL@G.BBN.COM
Subject: Re: (PROCLAIM '(IGNORE ...))
From: NGALL@G.BBN.COM
To: Fahlman@C.CS.CMU.EDU
Cc: KMP@SCRC-STONY-BROOK.ARPA, common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]19-Apr-86 17:36:18.NGALL>
In-Reply-To: <FAHLMAN.12200150344.BABYL@C.CS.CMU.EDU>
Date: Sat, 19 Apr 1986 16:07 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: (PROCLAIM '(IGNORE ...))
In-Reply-To: Msg of 18 Apr 1986 00:50-EST from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
Message-ID: <FAHLMAN.12200150344.BABYL@C.CS.CMU.EDU>
Special treatment of IGNORE as a variable name was left out of the
language because a lot of people objected to having the language poke
holes in the namespace. (However, we relented with T, NIL, and the
various &... symbols.)
Where in the manual does it say or imply that a lambda-list keyword
cannot be used as a normal variable? To the contrary, pg 60 says,
"They are ordinary symbols each of whose names begins with an
ampersand."
The lexically scoped IGNORE declaration seemed a much cleaner solution.
I agree.
Allowing global IGNORE proclamations seems a bit unclean to me, since
I agree.
it can have an effect on variables that come in from God-knows-where and
that were never intended to be ignored. On the other hand, this would
not be disastrous -- it would result in a few spurious compiler warnings
in a few odd cases, and it wouldn't be at all hard to see what went
wrong.
So I wouldn't object to a decision that (PROCLAIM '(IGNORE ...))
is legal.
The definition of PROCLAIM on pg 156 says, "Any variable names
mentioned are assumed to refer to the dynamic values of the variable."
But the definition of IGNORE on pg. 160 says, "It is desirable for a
compiler to issue a warning if a variable so declared is ... also
declared special". Thus it is legal, but meaningless to PROCLAIM
IGNORE. If you are proposing that IGNORE be a special case that
refers to the lexical value (or lack thereof) of mentioned variable
names, I would be stronly against it; the semantics of PROCLAIM are
confusing enough already. Also, once IGNORE can be used on lexicals
in a proclaim, why not TYPE also, then I wouldn't have to put a
declare in each function that share a common parameter.
No, I would contend that the need does not outweigh the consequences.
-- Scott
--------------------
-- Nick
∂19-Apr-86 1537 SOLEY@MC.LCS.MIT.EDU (PROCLAIM '(IGNORE ...))
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 19 Apr 86 15:36:29 PST
Date: Sat, 19 Apr 86 18:37:59 EST
From: Richard Mark Soley <SOLEY@MC.LCS.MIT.EDU>
Subject: (PROCLAIM '(IGNORE ...))
To: Fahlman@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA, KMP@SCRC-STONY-BROOK.ARPA
In-reply-to: Msg of Sat 19 Apr 1986 16:07 EST from Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
Message-ID: <[MC.LCS.MIT.EDU].889436.860419.SOLEY>
Date: Sat, 19 Apr 1986 16:07 EST
From: Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
Sender: FAHLMAN at C.CS.CMU.EDU
The lexically scoped IGNORE declaration seemed a much cleaner solution.
Allowing global IGNORE proclamations seems a bit unclean to me, since
it can have an effect on variables that come in from God-knows-where and
that were never intended to be ignored. On the other hand, this would
not be disastrous -- it would result in a few spurious compiler warnings
in a few odd cases, and it wouldn't be at all hard to see what went
wrong.
Additionally, the package system offers some protection against this.
I don't think Kent was suggesting that (PROCLAIM '(IGNORE FNORX))
should cause ignorance of all symbols string-equal to "FNORX"!
Note the difference with Zetalisp, in which all variables STRING-equal
to IGNORE are "ignore"d.
-- Richard
∂19-Apr-86 1612 NGALL@G.BBN.COM true-list type specifier
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 19 Apr 86 16:12:06 PST
Date: 19 Apr 1986 19:11-EST
Sender: NGALL@G.BBN.COM
Subject: true-list type specifier
From: NGALL@G.BBN.COM
To: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]19-Apr-86 19:11:32.NGALL>
Since we seem to be on the subject of type specifiers, let me add this
question. Given the following code
(defun foo (my-list)
(declare (list my-list))
(member 'my my-list))
and a compiler that has been told to turn off type-checking where
licenced by user declarations. One might assume that MEMBER need not
do a LIST check on each CDR of MY-LIST. But this is not the case, the
above declaration merely licences the compiler to assume that MY-LIST
is NIL or a CONS, but a type check should still be done on the CDR of
MY-LIST (when it is a CONS), and on its CDR, etc.
My question is: How does one declare that MY-LIST is a true list?
For the purpose of discrimination, I suppose the following would
suffice:
(deftype true-list ()
'(or null (and cons (satisfies true-list-p))))
(defun true-cons-p (cons)
(declare (cons cons))
(null (last cons)))
But this would not be usable for purposes of declaration (unless one
was dealing with an AI compiler :->).
So I propose that the type specifier true-list be introduced. This
would then allow compilers to validly substitute a NULL test for a
NULL/CONSP test in the case mentioned above.
-- Nick
∂20-Apr-86 0742 FAHLMAN@C.CS.CMU.EDU true-list type specifier
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 20 Apr 86 07:39:17 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 20 Apr 86 10:41:49-EST
Date: Sun, 20 Apr 1986 10:41 EST
Message-ID: <FAHLMAN.12200353201.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: NGALL@BBNG.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: true-list type specifier
In-reply-to: Msg of 19 Apr 1986 19:11-EST from NGALL at G.BBN.COM
(defun foo (my-list)
(declare (list my-list))
(member 'my my-list))
and a compiler that has been told to turn off type-checking where
licenced by user declarations. One might assume that MEMBER need not
do a LIST check on each CDR of MY-LIST. But this is not the case, the
above declaration merely licences the compiler to assume that MY-LIST
is NIL or a CONS, but a type check should still be done on the CDR of
MY-LIST (when it is a CONS), and on its CDR, etc.
My question is: How does one declare that MY-LIST is a true list?
You're wrong here. The term "list" already means what you want
to call a "true list". See the definition on page 26.
-- Scott
∂20-Apr-86 0831 FAHLMAN@C.CS.CMU.EDU (PROCLAIM '(IGNORE ...))
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 20 Apr 86 08:31:19 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 20 Apr 86 11:33:31-EST
Date: Sun, 20 Apr 1986 11:33 EST
Message-ID: <FAHLMAN.12200362614.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: NGALL@BBNG.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: (PROCLAIM '(IGNORE ...))
In-reply-to: Msg of 19 Apr 1986 17:36-EST from NGALL at G.BBN.COM
Where in the manual does it say or imply that a lambda-list keyword
cannot be used as a normal variable? To the contrary, pg 60 says,
"They are ordinary symbols each of whose names begins with an
ampersand."
Hmmm...I guess it never comes right out and says that, probably because
it was too obvious to mention. At least, it seems very clear to me that
the lambda-list keywords cannot be used as normal variables in
lambda-lists. Most such uses would screw up the parsing, and any that
are not ambiguous by would be confusing as hell. Most exisitng
compilers warn about any lambda-list keywords that seem to be out of
order in a lambda list, and some compilers issue a warning about any
unknown symbol starting with an ampersand. Such symbols are not
illegal, but a warning doesn't imply illegality -- merely something
suspicious that the user might want to take a close look at.
I suppose one could argue that lambda-list keywords ought to be legal as
variable names in non-lambda contexts. I think that this should be
illegal -- it is amazingly confusing -- but by a strict reading of the
current manual, I guess it is legal at present.
Maybe the best way to resolve this IGNORE issue is to leave the language
spec as it is, but to encourage compiler writers to provide some
mechanism whereby the user can specify that certain classes of warnings
can be suppressed. In this case, one would like to suppress "bound but
not referenced" warnings for particular symbols.
There's a more general issue here regarding compiler warnings:
Spurious compiler warnings seem to bother some people more than others.
I have generally taken the view that if the compiler spots something
vaguely suspicious, even if it is not clearly incorrect, it can't hurt
to issue a warning. It costs very little to ignore such a warning, and
if the problem is a real one, you might save the user many hours of
debugging time. However, some individuals and companies seem to believe
that code is not in a presentable state until all compiler warnings have
been eliminated, either by fixing the code or by explicitly suppressing
the error message.
At present, the language spec does not say what warnings a compiler must
or may issue, and there is nothing in the spec about suppressing such
warnings. One reasonable position (that looks good to me) is that this
is an environment issue and the language doesn't need to say anything
about this. But if people are going to get upset when allegedly
portable programs give rise to compiler warnings, then maybe we need to
think about some standard in-file mechanism (perhaps an extension to
Proclaim/Declare, or perhaps something new) for suppressing certain
classes of warnings at various places within a file. Such a thing would
provide a common language for creating such advisories, but it would not
be mandatory for compilers to pay any attention to them -- just
desirable.
-- Scott
∂20-Apr-86 0846 FAHLMAN@C.CS.CMU.EDU Type Specifier: (OR (FUNCTION ...) ...)
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 20 Apr 86 08:46:02 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 20 Apr 86 11:47:49-EST
Date: Sun, 20 Apr 1986 11:47 EST
Message-ID: <FAHLMAN.12200365217.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: NGALL@BBNG.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: Type Specifier: (OR (FUNCTION ...) ...)
In-reply-to: Msg of 19 Apr 1986 17:08-EST from NGALL at G.BBN.COM
Your proposal for an extension of the current declaration machinery so
that there is a richer langauge in which to express constraints to the
compiler looks interesting. I don't have any specific objections to
what you propose -- it may be the right thing. However, I think that
this is an area in which there are several possible approaches, and I
would like to see some systematic exploration and some real experience
here before we start extending the language spec piecemeal.
I would suggest that if you want to experiment in this area, you develop
a non-standard but compatible superset of the current declaration
language, and that you install this in an experimental version of your
system along with a compiler that uses this information. I'd like to
see this in a context that includes CommonLoops or New Flavors, since
there are some strong parallels between the kind of type-restricted
arguments that those systems support and the sort of thing that you
propose for declarations. If actual experience shows that this is a
good way to go, then it would be time to seriously consider extending
the standard in this way. If it is impractical for people out in
industry to try this, maybe it would make a good M.S. thesis project for
someone.
-- Scott
∂20-Apr-86 0949 NGALL@G.BBN.COM Re: true-list type specifier
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 20 Apr 86 09:49:31 PST
Date: 20 Apr 1986 12:48-EST
Sender: NGALL@G.BBN.COM
Subject: Re: true-list type specifier
From: NGALL@G.BBN.COM
To: Fahlman@C.CS.CMU.EDU
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]20-Apr-86 12:48:43.NGALL>
In-Reply-To: <FAHLMAN.12200353201.BABYL@C.CS.CMU.EDU>
Date: Sun, 20 Apr 1986 10:41 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: NGALL@BBNG.ARPA
Subject: true-list type specifier
In-Reply-To: Msg of 19 Apr 1986 19:11-EST from NGALL at G.BBN.COM
Message-ID: <FAHLMAN.12200353201.BABYL@C.CS.CMU.EDU>
(defun foo (my-list)
(declare (list my-list))
(member 'my my-list))
and a compiler that has been told to turn off type-checking where
licenced by user declarations. One might assume that MEMBER need not
do a LIST check on each CDR of MY-LIST. But this is not the case, the
above declaration merely licences the compiler to assume that MY-LIST
is NIL or a CONS, but a type check should still be done on the CDR of
MY-LIST (when it is a CONS), and on its CDR, etc.
My question is: How does one declare that MY-LIST is a true list?
You're wrong here. The term "list" already means what you want
to call a "true list". See the definition on page 26.
-- Scott
--------------------
No, you're wrong here. On pg. 27 it says: "The Lisp data type LIST is
taken to mean the union of the CONS and NULL data types, and therefore
encompasses both true lists and dotted lists."
So my question and proposal still stand. Although I would not be
against redefining LIST to mean true-list and using
(OR NULL CONS) to mean true-or-dotted-list. But this would be an
incompatible change, which might be harder to get into the language.
-- Nick
∂20-Apr-86 1313 gls@THINK-AQUINAS.ARPA Re: Type Specifier: (OR (FUNCTION ...) ...)
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 20 Apr 86 13:13:03 PST
Received: from yon by GODOT.THINK.COM via CHAOS; Sun, 20 Apr 86 16:13:43 est
Date: Sun, 20 Apr 86 16:14 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Re: Type Specifier: (OR (FUNCTION ...) ...)
To: NGALL@G.BBN.COM, Fahlman@C.CS.CMU.EDU
Cc: common-lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA
In-Reply-To: <[G.BBN.COM]19-Apr-86 17:08:16.NGALL>
Message-Id: <860420161452.2.GLS@THINK-YON.ARPA>
Date: 19 Apr 1986 17:08-EST
From: NGALL@G.BBN.COM
Date: Sat, 19 Apr 1986 16:24 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Regarding your proposal that we allow forms like the following
(or (function (list) list)
(function (vector) vector))
as a way of specifying that the output type of a function matches its
input type...
Your proposal seems to take one small step in the direction
of such a declarative language, and then it stops.
...
...
I don't think it is a proposal. I can find nothing in CLtL that forbids
using such a form right now. I find no justification in CLtL for a
compiler's insisting that a type specifier given to FTYPE be of the form
(FUNCTION ...). Unless a compiler can prove that a declaration is
actually inconsistent, it should not signal an error. (Warnings are
another matter and, as always, subject to judements of taste.) A compiler
is not justified in signalling an error just because it doesn't know
how to make use of a perfectly legitimate declaration.
... If someone were to say
(or (function (list sequence) foo)
(function (sequence list) bar))
then what do we do?
According to the definition of the OR type-spec on pg. 45, "it always
tests each of the component types in order from left to right and
stops procesing as soon as one component of the union has been found
to which the object belongs."
But hold on here, now. That specification applies specifically to the case
of TYPEP processing the type specifier, not to the case of using the type
specifier in a declaration. Also, do not make the mistake of thinking that
that one can decide which of several function type specifiers applies to
a function call by examining the argument types only. If function BAZ has
the type shown above, then we are entitled only to conclude that the
call (BAZ '(a) '(b)) will return an object of type (OR FOO BAR).
But here is a more subtle point. The above type states that BAZ is either
a function of type (FUNCTION (LIST SEQUENCE) FOO) or a function of type
(FUNCTION (SEQUENCE LIST) BAR). Assume FOO and BAR to be disjoint types.
Suppose BAZ is called twice in succession, and the result of the first call
is determined to be of type FOO:
(WHEN (TYPEP (BAZ '(a) '(b)) 'FOO)
(BAZ '(c) '(d)))
We have no cause to believe that BAZ will change between the two calls,
and so we are entitled to deduce that the second call to BAZ, if
executed, will necessarily return a FOO and not a BAR, because the first
call produced a FOO and thus BAZ is of type (FUNCTION (LIST SEQUENCE) FOO).
So maybe Nick isn't actually expressing quite what he wanted to in the
first place.
--Guy
∂20-Apr-86 1325 gls@THINK-AQUINAS.ARPA (PROCLAIM '(IGNORE ...))
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 20 Apr 86 13:24:40 PST
Received: from yon by GODOT.THINK.COM via CHAOS; Sun, 20 Apr 86 16:25:29 est
Date: Sun, 20 Apr 86 16:26 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: (PROCLAIM '(IGNORE ...))
To: Fahlman@C.CS.CMU.EDU, NGALL@BBNG.ARPA
Cc: common-lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA
In-Reply-To: <FAHLMAN.12200362614.BABYL@C.CS.CMU.EDU>
Message-Id: <860420162638.3.GLS@THINK-YON.ARPA>
Date: Sun, 20 Apr 1986 11:33 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Where in the manual does it say or imply that a lambda-list keyword
cannot be used as a normal variable? To the contrary, pg 60 says,
"They are ordinary symbols each of whose names begins with an
ampersand."
Hmmm...I guess it never comes right out and says that, probably because
it was too obvious to mention. At least, it seems very clear to me that
the lambda-list keywords cannot be used as normal variables in
lambda-lists. Most such uses would screw up the parsing, and any that
are not ambiguous by would be confusing as hell. Most exisitng
compilers warn about any lambda-list keywords that seem to be out of
order in a lambda list, and some compilers issue a warning about any
unknown symbol starting with an ampersand. Such symbols are not
illegal, but a warning doesn't imply illegality -- merely something
suspicious that the user might want to take a close look at.
See page 65, in the middle.
--Guy
∂20-Apr-86 1402 REM@IMSSS What really are semantics of (OR ...) type specifier??
Date: 1986 April 20 14:01:58 PST (=GMT-8hr)
From: Robert Elton Maas <REM%IMSSS@SU-AI.ARPA>
To:COMMON-LISP@SU-AI
Subject:What really are semantics of (OR ...) type specifier??
G> Date: Sun, 20 Apr 86 16:14 EST
G> From: Guy Steele <gls@THINK-AQUINAS.ARPA>
G> Subject: Re: Type Specifier: (OR (FUNCTION ...) ...)
(or (function (list) list)
(function (vector) vector))
as a way of specifying that the output type of a function matches its
input type...
G> ...
G> But here is a more subtle point. The above type states that BAZ is either
G> a function of type (FUNCTION (LIST SEQUENCE) FOO) or a function of type
G> (FUNCTION (SEQUENCE LIST) BAR). Assume FOO and BAR to be disjoint types.
G> Suppose BAZ is called twice in succession, and the result of the first call
G> is determined to be of type FOO:
G> (WHEN (TYPEP (BAZ '(a) '(b)) 'FOO)
G> (BAZ '(c) '(d)))
G> We have no cause to believe that BAZ will change between the two calls,
G> and so we are entitled to deduce that the second call to BAZ, if
G> executed, will necessarily return a FOO and not a BAR, because the first
G> call produced a FOO and thus BAZ is of type (FUNCTION (LIST SEQUENCE) FOO).
G> So maybe Nick isn't actually expressing quite what he wanted to in the
G> first place.
Very good analysis. (:- I'm glad such subtle points were carefully
studied before anybody publishes an official standard in book form -:)
My guess is nobody thought of this before, so the manual is ambiguous
and needs to be fixed (your interpretation, or his, or it's not legal CL).
One possible cook of your analysis, it's possible that since BAZ is
defined globally it may get defined out from under this program loop.
I.e. the code must fetch the function definition of BAZ twice rather
than fetch it once and use that fetched&cached value twice, so there's
nothing to stop BAZ from redefining itself each time it is called.
This is PSL but:
(DE BAZ1 (A B) (PROGN (COPYD 'BAZ 'BAZ2) ...))
(DE BAZ2 (A B) (PROGN (COPYD 'BAZ 'BAZ1) ...))
(COPYD BAZ 'BAZ1) ;; Initialize the flip-flop function
∂20-Apr-86 1402 REM@IMSSS Need way to suppress warning messages after first see
Date: 1986 April 20 13:49:52 PST (=GMT-8hr)
From: Robert Elton Maas <REM%IMSSS@SU-AI.ARPA>
To:COMMON-LISP@SU-AI
CC:"TRYG%IMSSS"@SCORE
Subject:Need way to suppress warning messages after first see
F> Date: Sun, 20 Apr 1986 11:33 EST
F> From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
F> Subject: (PROCLAIM '(IGNORE ...)) [SIC]
F> ...
F> Spurious compiler warnings seem to bother some people more than others.
F> I have generally taken the view that if the compiler spots something
F> vaguely suspicious, even if it is not clearly incorrect, it can't hurt
F> to issue a warning. It costs very little to ignore such a warning, and
F> if the problem is a real one, you might save the user many hours of
F> debugging time. However, some individuals and companies seem to believe
F> that code is not in a presentable state until all compiler warnings have
F> been eliminated, either by fixing the code or by explicitly suppressing
F> the error message.
Seeing and thinking and ignoring one warning once is no big problem,
it takes about a minute of my time, maybe less if it's something
halfway obvious, maybe five minutes if it's a really fatal looking
error I have to figure out carefully, maybe an hour if I have to
discuss it with my boss (for example CANNOT CHANGE FLUID TO GLOBAL or
vice versa in PSL). After I've hassled with one particular instance of
one particular warning a couple times I get more efficient, but the
total time wasted looking at the same error over and over and over
accumulates over the months I work on a system. If in building a large
system I have to look at a hundred warning messages each of a hundred
recompilations during development, that's ten thousand individual
lookings at those idiotic warnings. More likely I just get in the
habit of ignoring them en masse, which is where the harm happens,
because when an important new warning happens I never even look at it
much less study it, in fact I complete miss other obvious things like
DISK FULL, CANNOT OPEN OUTPUT FILE because I'm not even bothering to
eyeball the batch log file. -- Conclusion, it's absolutely essential
for proper use of programmer time and adequate detection of problems
to have a way to suppress individual instances of various warning
messages and in some cases whole classes of warning messages which are
known a priori never to be significant. Any LISP system that fails to
allow the programmer to suppress warnings is (in my opinion) unacceptable.
F> At present, the language spec does not say what warnings a compiler must
F> or may issue, and there is nothing in the spec about suppressing such
F> warnings.
Accompanying the language syntax&semantics spec should be important
guidelines, such as "the compiler should make the resultant as
efficient as possible without sacrificing correctness" (i.e. it's not
legal to sell a "compiler" that just passes most program source thru
to be interpreted at runtime), and "except for detection of outright
errors, it should be possible for the user/programmer to suppress
virtually all warnings and other unnecessary output, as selectively as
reasonable" (i.e. it should be possible to declare individual
names/objects (variables, and data or functions) as well as to declare
classes of names/objects or classes of messages). A general guideline
(desiderata) should be given, so that really obnoxious compilers can
be declared "technically Common LISP but not really in the spirit of
the language".
F> One reasonable position (that looks good to me) is that this
F> is an environment issue and the language doesn't need to say anything
F> about this.
Insufficient response (my opinion).
F> But if people are going to get upset when allegedly
F> portable programs give rise to compiler warnings, then ...
Yup, something is needed (my opinion).
∂20-Apr-86 1519 FAHLMAN@C.CS.CMU.EDU true-list type specifier
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 20 Apr 86 15:17:39 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 20 Apr 86 18:18:45-EST
Date: Sun, 20 Apr 1986 18:18 EST
Message-ID: <FAHLMAN.12200436381.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: NGALL@BBNG.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: true-list type specifier
In-reply-to: Msg of 20 Apr 1986 12:48-EST from NGALL at G.BBN.COM
You're wrong here. The term "list" already means what you want
to call a "true list". See the definition on page 26.
No, you're wrong here. On pg. 27 it says: "The Lisp data type LIST is
taken to mean the union of the CONS and NULL data types, and therefore
encompasses both true lists and dotted lists."
OK, now that you mention it, the statement at the bottom of page 27
seems to be more clearly applicable LIST as a type-specifier than the
definition on page 26.
I wonder if any exisitng code would break if we were to define the List
type-specifier to mean "true list"? Implementations would then be free
to use a null test instead of a consp test, though consp would also be
legal. My guess is that some implementations follow this convention
already, even though page 27 seems to label this an error.
-- Scott
∂20-Apr-86 1759 meehan@YALE.ARPA ignore
Received: from YALE-BULLDOG.ARPA by SU-AI.ARPA with TCP; 20 Apr 86 17:58:18 PST
Received: by Yale-Bulldog.YALE.ARPA; 19 Apr 86 14:01:22 EST (Sat)
Date: 19 Apr 86 14:01:22 EST (Sat)
From: James Meehan <meehan@YALE.ARPA>
Message-Id: <8604191901.AA01167@Yale-Bulldog.YALE.ARPA>
Subject: ignore
To: pitman@YALE.ARPA
Cc: common-lisp@su-ai.arpa
Personally, I've grown very fond of the T convention that allows you to
write () for ignored variables; e.g., (lambda (() y) y),
(multiple-value-bind (a () c) ...). The one hassle with that
convention in T, which was that (lambda (a b . ()) ...) doesn't "work,"
goes away in Common Lisp: (lambda (a b &rest ()) ...).
As far as compiler warnings are concerned, though,
I think they're still a good idea in a world of ipmerfect typists, but I
wouldn't mind seeing a switch to turn the warnings off.
-------
∂20-Apr-86 1930 DT50@A.CS.CMU.EDU IGNORE, warnings, and &stuff
Received: from A.CS.CMU.EDU by SU-AI.ARPA with TCP; 20 Apr 86 19:30:19 PST
Date: 20 Apr 86 22:32 EST
From: Dave.Touretzky@A.CS.CMU.EDU
To: common-lisp@SU-AI.ARPA
Subject: IGNORE, warnings, and &stuff
Since &-stuff in the lambda list is already treated as magic, I propose
adding a new lambda list keyword called &IGNORE. Writing
(lambda (x &ignore y &ignore z) ...)
should be equivalent to
(lambda (x g0001 y g0002 z)
(declare (ignore g0001 g0002))
...)
I agree that code is not acceptable if it generates compiler warnings,
because (a) it trains people to ignore compiler output, so they won't
notice when significant warnings appear in the middle of routine stuff, and
(b) people who port code to a new machine can't be expected to know which
warnings can safely be ignored, unless they read and analyze the entire
code.
For the same reasons, we should be careful about allowing users to turn off
entire classes of warnings just to silence a paranoid compiler. Instead. I
think compilers should be required to provide a declaration for each class
of warnings to locally specify that the user knows he is doing X and
doesn't need a warning about X in this instance. The IGNORE declaration is
a good example.
∂20-Apr-86 2019 FAHLMAN@C.CS.CMU.EDU IGNORE, warnings, and &stuff
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 20 Apr 86 20:17:07 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 20 Apr 86 23:19:38-EST
Date: Sun, 20 Apr 1986 23:19 EST
Message-ID: <FAHLMAN.12200491148.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Dave.Touretzky@A.CS.CMU.EDU
Cc: common-lisp@SU-AI.ARPA
Subject: IGNORE, warnings, and &stuff
In-reply-to: Msg of 20 Apr 1986 22:32-EST from Dave.Touretzky at A.CS.CMU.EDU
Since &-stuff in the lambda list is already treated as magic, I propose
adding a new lambda list keyword called &IGNORE. Writing
(lambda (x &ignore y &ignore z) ...)
should be equivalent to
(lambda (x g0001 y g0002 z)
(declare (ignore g0001 g0002))
...)
I really don't like this. The other &-thingies are punctuation within
the lambda list which separate the variables into groups; they are not
stand-ins or place-holders for the variables themselves. At present,
users can scan a lambda list and see each top-level item in the list
grabs one of the arguments unless it is one of these &-markers. &IGNORE
would mess this up.
I would find IGNORE much less objectionable than &IGNORE in this role,
even if it carves one extra symbol out of the namespace. But I still
think that the existing IGNORE declaration does the job just fine,
except in code passed down from the ancients.
-- Scott
∂21-Apr-86 0035 Moon@SCRC-STONY-BROOK.ARPA What is a compiler (vol. 63827) meets what are gensyms.
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 21 Apr 86 00:32:42 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 467615; Sat 19-Apr-86 18:19:54-EST
Date: Sat, 19 Apr 86 18:19 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: What is a compiler (vol. 63827) meets what are gensyms.
To: Common-Lisp@SU-AI.ARPA
In-Reply-To: <860417141538.0.GREGOR@AVALON.XEROX-PARC>
Message-ID: <860419181953.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
I don't think this is a language issue at all. I think it's simply a
bug in the implementation. Compiling
(DEFSETF BAR (#:G1890) (#:G1891) `(SET-BAR ,#:G1890 ,#:G1891)),
where the symbols that look the same are EQ, is certainly supposed to
work. I'm not sure I understood what Fahlman said, but he and I are
probably saying the same thing.
∂21-Apr-86 0106 DCP@ALLEGHENY.SCRC.Symbolics.COM What is a compiler (vol. 63827) meets what are gensyms.
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 21 Apr 86 01:05:45 PST
Received: from FIREBIRD.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 12719; Fri 18-Apr-86 10:20:10-EST
Date: Fri, 18 Apr 86 10:17 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: What is a compiler (vol. 63827) meets what are gensyms.
To: Gregor.pa@Xerox.COM, Common-Lisp@SU-AI.ARPA
In-Reply-To: <860417141538.0.GREGOR@AVALON.XEROX-PARC>
Supersedes: <860418101707.7.DCP@FIREBIRD.SCRC.Symbolics.COM>
Message-ID: <860418101724.8.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Thu, 17 Apr 86 14:15 PST
From: Gregor.pa@Xerox.COM
In this issue the subject of what compile file is required to do with
top-level forms meets the subject of top-level calls to macros which
expand into code containing gensyms.
Suppose I have the following macro.
(defmacro foo (x y)
(let ((var (gensym))
(nv-var (gensym)))
`(progn
(defun ,x ..)
(defun ,y ..)
(defsetf ,x (,var) (,nv-var) `(,',y ,,var ,,nv-var)))))
And I have a file that includes the form:
(FOO BAR SET-BAR)
[ For clarities sake, the point is that the macro expands
to a progn that includes a defsetf that has gensyms for
the access-function-args and storing-variables, like this:
(DEFSETF BAR (#:G1890) (#:G1891) `(SET-BAR ,#:G1890 ,#:G1891))
]
Is compiling and loading the file legal Common Lisp?
Is the original foo macro legal Common Lisp?
I claim that the answer to both questions is yes. After all, it is
clearly legal interpreted/compiled to core Common Lisp.
I believe that CLtL is "silent" on this issue.
I got bit by a Common Lisp compiler which macroexpands top-level forms,
but which does not necessarily compile the entire result of the
macroexpansion. In this particular case the compiler expanded the two
defuns, but left the defsetf as (store-setf '<list with gensyms in it>)
Then the dumper dumped that list in such a way that when the file was
loaded the gensyms which should have been eq were not.
My opinion is that what you are doing is legal. My guess is that the
dumper/loader you are using dumps all symbols as (more-or-less)
package::print-name. This WILL preserve EQness for non-gensyms but
loses for gensyms.
I think CLtL must be very explicit about what is preserved in the
load/dump process. The Symbolics implementation is EQUAL (often EQL)
for lists and EQL for everything else.
∂21-Apr-86 0106 DCP@ALLEGHENY.SCRC.Symbolics.COM What is a compiler (vol. 63827) meets what are gensyms.
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 21 Apr 86 01:02:20 PST
Received: from FIREBIRD.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 12718; Fri 18-Apr-86 10:19:54-EST
Date: Fri, 18 Apr 86 10:17 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: What is a compiler (vol. 63827) meets what are gensyms.
To: Gregor.pa@Xerox.COM, Common-Lisp@SU-AI.ARPA
In-Reply-To: <860417141538.0.GREGOR@AVALON.XEROX-PARC>
Message-ID: <860418101707.7.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Thu, 17 Apr 86 14:15 PST
From: Gregor.pa@Xerox.COM
In this issue the subject of what compile file is required to do with
top-level forms meets the subject of top-level calls to macros which
expand into code containing gensyms.
Suppose I have the following macro.
(defmacro foo (x y)
(let ((var (gensym))
(nv-var (gensym)))
`(progn
(defun ,x ..)
(defun ,y ..)
(defsetf ,x (,var) (,nv-var) `(,',y ,,var ,,nv-var)))))
And I have a file that includes the form:
(FOO BAR SET-BAR)
[ For clarities sake, the point is that the macro expands
to a progn that includes a defsetf that has gensyms for
the access-function-args and storing-variables, like this:
(DEFSETF BAR (#:G1890) (#:G1891) `(SET-BAR ,#:G1890 ,#:G1891))
]
Is compiling and loading the file legal Common Lisp?
Is the original foo macro legal Common Lisp?
I claim that the answer to both questions is yes. After all, it is
clearly legal interpreted/compiled to core Common Lisp.
I believe that CLtL is "silent" on this issue.
I got bit by a Common Lisp compiler which macroexpands top-level forms,
but which does not necessarily compile the entire result of the
macroexpansion. In this particular case the compiler expanded the two
defuns, but left the defsetf as (store-setf '<list with gensyms in it>)
Then the dumper dumped that list in such a way that when the file was
loaded the gensyms which should have been eq were not.
My opinion is that what you are doing is legal. My guess is that the
dumper/loader you are using dumps all symbols as (more-or-less)
package::print-name. This WILL preserve EQness for non-gensyms but
loses for gensyms.
I think CLtL must be very explicit about what is preserved in the
load/dump process. The Symbolics implementation is EQUAL for lists and
EQL for everything else.
∂21-Apr-86 0722 @MIT-LIVE-OAK.ARPA:Soley@MIT-MC.ARPA IGNORE, warnings, and &stuff
Received: from MIT-LIVE-OAK.ARPA by SU-AI.ARPA with TCP; 21 Apr 86 07:22:09 PST
Received: from MIT-CHERRY.ARPA by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 701; Mon 21-Apr-86 10:22:58-EST
Date: Mon, 21 Apr 86 10:23 EST
From: Soley@MIT-MC.ARPA
Subject: IGNORE, warnings, and &stuff
To: Fahlman@C.CS.CMU.EDU, Dave.Touretzky@A.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12200491148.BABYL@C.CS.CMU.EDU>
Message-ID: <860421102327.4.SOLEY@MIT-CHERRY.ARPA>
Date: Sun, 20 Apr 1986 23:19 EST
Message-ID: <FAHLMAN.12200491148.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Since &-stuff in the lambda list is already treated as magic, I propose
adding a new lambda list keyword called &IGNORE. Writing
(lambda (x &ignore y &ignore z) ...)
should be equivalent to
(lambda (x g0001 y g0002 z)
(declare (ignore g0001 g0002))
...)
I really don't like this. The other &-thingies are punctuation within
the lambda list which separate the variables into groups; they are not
stand-ins or place-holders for the variables themselves.
I agree. In addition, you don't get the argument list documentation of
the names of the ignored variables. But how about if
(lambda (x &ignore y &ignore z) ...)
was instead the same as
(lambda (x y z)
(declare (ignore y z))
...)
??
-- Richard
∂21-Apr-86 0754 FAHLMAN@C.CS.CMU.EDU IGNORE, warnings, and &stuff
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 21 Apr 86 07:49:21 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 21 Apr 86 10:51:42-EST
Date: Mon, 21 Apr 1986 10:51 EST
Message-ID: <FAHLMAN.12200617110.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Soley@MC.LCS.MIT.EDU
Cc: common-lisp@SU-AI.ARPA
Subject: IGNORE, warnings, and &stuff
In-reply-to: Msg of 21 Apr 1986 10:23-EST from Soley at MIT-MC.ARPA
But how about if
(lambda (x &ignore y &ignore z) ...)
was instead the same as
(lambda (x y z)
(declare (ignore y z))
...)
I don't see this as any big improvement in convenience over the declare
form we have now.
-- Scott
∂21-Apr-86 0828 KMP@SCRC-STONY-BROOK.ARPA [marchett%cod@nosc: slotp]
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 21 Apr 86 08:26:15 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 468268; Mon 21-Apr-86 11:25:11-EST
Date: Mon, 21 Apr 86 11:26 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: [marchett%cod@nosc: slotp]
To: Common-Lisp@SU-AI.ARPA
Message-ID: <860421112614.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
The following came just to me, but as long as he's taken the trouble
to write all this down, it might as well be archived...
Date: Mon, 21 Apr 86 07:20:53 PST
From: David J. Marchette <marchett%cod@nosc.ARPA>
To: kmp@scrc-stony-brook
Cc: priebe%cod@nosc.ARPA
Subject: slotp
Message-Id: <8604211520.AA09291@cod.ARPA>
I had several reasons for asking the question. I admit it sounds
silly that the person who did the programming wouldn't know what
he called the slots. That isn't what I'm talking about here. The
problem is that I am writing a rule parser similar to ops5, but with
a more object-oriented view point. A rule may deal with several
objects, or structures, and there may be many different kinds of
data objects. When the time comes to test the rules, the program
needs a way of determining which objects are valid data for the
rules, and this cannot be written in to the rule language. I realize
that there are other ways to do this, but it seemed to be an easy
quick and dirty way to get things going if I could check the data objects
to see if they had the necessary structure for that particular rule. A
second reason for doing this is that it would be nice to be able to have
a simple way of viewing the data built in to the rule language. The
Symbolics has such a tool, called the inspector, which allows one to
see the values of the slots and prints the "name" of the slot next to
it. The inspector of course cannot know ahead of time what kind of data
it will be given. Finally, the fact that a debugger may want to have
this ability is another argument for making it a part of the language
since this would make one more part of the debugger implementation
independant. After all, someone has to write debuggers. Since, as I
understand it, there is nothing forcing an implementation to store
structures in a particular way, there may be no way to get this information
in an implementation independant way unless the implementer also provides
a function to do this. I may be wrong, they may always store the names
of slots in a property list, in which case I have no problem, but I don't
want to write code that will only run on my symbolics. If I'm going to
do that, I might as well stick with zetalisp with all the good stuff it
gives me.
∂21-Apr-86 1031 meehan@YALE.ARPA *print-circle*
Received: from YALE-BULLDOG.ARPA by SU-AI.ARPA with TCP; 21 Apr 86 10:31:17 PST
Received: by Yale-Bulldog.YALE.ARPA; 21 Apr 86 13:09:51 EST (Mon)
Date: 21 Apr 86 13:09:51 EST (Mon)
From: James Meehan <meehan@YALE.ARPA>
Message-Id: <8604211809.AA03911@Yale-Bulldog.YALE.ARPA>
Subject: *print-circle*
To: common-lisp@su-ai.arpa
When *print-circle* is true, the printer should "endeavor to detect
circularities" in the thing it's printing. Is this supposed to
include structures that have :print-function methods? I know it's
more work, but it seems like the right thing.
-------
∂21-Apr-86 1314 mips!pachyderm.earl@su-glacier.arpa IGNORE, warnings, and &stuff
Received: from SU-GLACIER.ARPA by SU-AI.ARPA with TCP; 21 Apr 86 13:14:16 PST
Received: by su-glacier.arpa with Sendmail; Mon, 21 Apr 86 13:01:50 pst
Received: from pachyderm.UUCP (pachyderm.ARPA) by mips.UUCP (4.12/4.7)
id AA11916; Mon, 21 Apr 86 12:07:26 pst
Received: by pachyderm.UUCP (4.12/4.7)
id AA24766; Mon, 21 Apr 86 12:06:47 pst
Date: Mon, 21 Apr 86 12:06:47 pst
From: mips!pachyderm.earl@su-glacier.arpa (Earl Killian)
Message-Id: <8604212006.AA24766@pachyderm.UUCP>
To: common-lisp@SU-AI.ARPA
Subject: IGNORE, warnings, and &stuff
Naming a variable IGNORE is not a general solution: how do I ignore
multiple arguments? Writing IGNORE multiple times would probably give
me complaints about using a variable name twice in the lambda list.
∂21-Apr-86 1334 NGALL@G.BBN.COM Re: Type Specifier: (OR (FUNCTION ...) ...)
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 21 Apr 86 13:33:39 PST
Date: 21 Apr 1986 16:31-EST
Sender: NGALL@G.BBN.COM
Subject: Re: Type Specifier: (OR (FUNCTION ...) ...)
From: NGALL@G.BBN.COM
To: gls@AQUINAS.THINK.COM
Cc: Fahlman@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]21-Apr-86 16:31:40.NGALL>
In-Reply-To: <860420161452.2.GLS@THINK-YON.ARPA>
Date: Sun, 20 Apr 86 16:14 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Date: 19 Apr 1986 17:08-EST
From: NGALL@G.BBN.COM
Date: Sat, 19 Apr 1986 16:24 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Regarding your proposal that we allow forms like the following
(or (function (list) list)
(function (vector) vector))
as a way of specifying that the output type of a function matches its
input type...
...
I don't think it is a proposal. I can find nothing in CLtL that forbids
using such a form right now. I find no justification in CLtL for a
compiler's insisting that a type specifier given to FTYPE be of the form
(FUNCTION ...).
What I said in my original letter was:
"Unfortunately, it is not clear from pg. 158 whether or not the
following is legal: ... It is not legal in VaxLisp, and my guess is
that there aren't any implementations that would do the right thing
with it. So I would like to propose that such a use of OR/FUNCTION be
considered legal CL."
I guess I should have said "So I would like to propose that pg. 158 be
'clarified' to explicitly state that such a use of OR/FUNCTION be
considered legal CL." To be more explicit: Clarify the def. of FTYPE
(pg. 158) by changing (FTYPE type ...) to (FTYPE function-type ...)
and defining function-type to either (FUNCTION ...),
(NOT function-type), (AND function-type ...), or (OR function-type ...).
I would still like to know if there are any implementations that do
consider (OR (FUNCTION ... meaningful!
Unless a compiler can prove that a declaration is
actually inconsistent, it should not signal an error. (Warnings are
another matter and, as always, subject to judements of taste.) A compiler
is not justified in signalling an error just because it doesn't know
how to make use of a perfectly legitimate declaration.
... If someone were to say
(or (function (list sequence) foo)
(function (sequence list) bar))
then what do we do?
According to the definition of the OR type-spec on pg. 45, "it always
tests each of the component types in order from left to right and
stops procesing as soon as one component of the union has been found
to which the object belongs."
But hold on here, now. That specification applies specifically to the case
of TYPEP processing the type specifier, not to the case of using the type
specifier in a declaration. Also, do not make the mistake of thinking
that one can decide which of several function type specifiers applies to
a function call by examining the argument types only. If function BAZ has
the type shown above, then we are entitled only to conclude that the
call (BAZ '(a) '(b)) will return an object of type (OR FOO BAR).
I stand corrected.
But here is a more subtle point. The above type states that BAZ is either
a function of type (FUNCTION (LIST SEQUENCE) FOO) or a function of type
(FUNCTION (SEQUENCE LIST) BAR). Assume FOO and BAR to be disjoint types.
Suppose BAZ is called twice in succession, and the result of the first call
is determined to be of type FOO:
(WHEN (TYPEP (BAZ '(a) '(b)) 'FOO)
(BAZ '(c) '(d)))
We have no cause to believe that BAZ will change between the two calls,
I disagree for the same reason as REM.
and so we are entitled to deduce that the second call to BAZ, if
executed, will necessarily return a FOO and not a BAR, because the first
call produced a FOO and thus BAZ is of type (FUNCTION (LIST SEQUENCE) FOO).
So maybe Nick isn't actually expressing quite what he wanted to in the
first place.
--Guy
No I guess I'm not. But I am quite happy with Guy's correction. I
can still do things like:
(proclaim '(ftype (or (function (t list &rest t) list)
(function (t vector &rest t) vector))
remove))
And expect that a very good compiler would be able to deduce that the
call (remove 1 '#(1 2 3 4)) will return a vector. I think I will now
try to come up with a declaration for +.
-- Nick
∂21-Apr-86 1407 RZ@MIT-ZERMATT.ARPA Re: Type Specifier: (OR (FUNCTION ...) ...)
Received: from MIT-ZERMATT.ARPA by SU-AI.ARPA with TCP; 21 Apr 86 14:06:51 PST
Received: from VIOLIN.LCS.MIT.EDU by MIT-ZERMATT.ARPA via CHAOS with CHAOS-MAIL id 34013; Mon 21-Apr-86 17:07:52-EST
Date: Mon, 21 Apr 86 17:07 EST
From: Richard E. Zippel <RZ@MIT-ZERMATT.ARPA>
Subject: Re: Type Specifier: (OR (FUNCTION ...) ...)
To: NGALL@G.BBN.COM, gls@AQUINAS.THINK.COM
cc: Fahlman@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA
In-Reply-To: <[G.BBN.COM]21-Apr-86 16:31:40.NGALL>
Message-ID: <860421170750.1.RZ@VIOLIN.LCS.MIT.EDU>
Date: 21 Apr 1986 16:31-EST
From: NGALL@G.BBN.COM
Date: Sun, 20 Apr 86 16:14 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Date: 19 Apr 1986 17:08-EST
From: NGALL@G.BBN.COM
Date: Sat, 19 Apr 1986 16:24 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Regarding your proposal that we allow forms like the following
(or (function (list) list)
(function (vector) vector))
as a way of specifying that the output type of a function matches its
input type...
...
I don't think it is a proposal. I can find nothing in CLtL that forbids
using such a form right now. I find no justification in CLtL for a
compiler's insisting that a type specifier given to FTYPE be of the form
(FUNCTION ...).
What I said in my original letter was:
"Unfortunately, it is not clear from pg. 158 whether or not the
following is legal: ... It is not legal in VaxLisp, and my guess is
that there aren't any implementations that would do the right thing
with it. So I would like to propose that such a use of OR/FUNCTION be
considered legal CL."
I guess I should have said "So I would like to propose that pg. 158 be
'clarified' to explicitly state that such a use of OR/FUNCTION be
considered legal CL." To be more explicit: Clarify the def. of FTYPE
(pg. 158) by changing (FTYPE type ...) to (FTYPE function-type ...)
and defining function-type to either (FUNCTION ...),
(NOT function-type), (AND function-type ...), or (OR function-type ...).
I would still like to know if there are any implementations that do
consider (OR (FUNCTION ... meaningful!
Unless a compiler can prove that a declaration is
actually inconsistent, it should not signal an error. (Warnings are
another matter and, as always, subject to judements of taste.) A compiler
is not justified in signalling an error just because it doesn't know
how to make use of a perfectly legitimate declaration.
... If someone were to say
(or (function (list sequence) foo)
(function (sequence list) bar))
then what do we do?
According to the definition of the OR type-spec on pg. 45, "it always
tests each of the component types in order from left to right and
stops procesing as soon as one component of the union has been found
to which the object belongs."
But hold on here, now. That specification applies specifically to the case
of TYPEP processing the type specifier, not to the case of using the type
specifier in a declaration. Also, do not make the mistake of thinking
that one can decide which of several function type specifiers applies to
a function call by examining the argument types only. If function BAZ has
the type shown above, then we are entitled only to conclude that the
call (BAZ '(a) '(b)) will return an object of type (OR FOO BAR).
I stand corrected.
But here is a more subtle point. The above type states that BAZ is either
a function of type (FUNCTION (LIST SEQUENCE) FOO) or a function of type
(FUNCTION (SEQUENCE LIST) BAR). Assume FOO and BAR to be disjoint types.
Suppose BAZ is called twice in succession, and the result of the first call
is determined to be of type FOO:
(WHEN (TYPEP (BAZ '(a) '(b)) 'FOO)
(BAZ '(c) '(d)))
We have no cause to believe that BAZ will change between the two calls,
I disagree for the same reason as REM.
and so we are entitled to deduce that the second call to BAZ, if
executed, will necessarily return a FOO and not a BAR, because the first
call produced a FOO and thus BAZ is of type (FUNCTION (LIST SEQUENCE) FOO).
So maybe Nick isn't actually expressing quite what he wanted to in the
first place.
--Guy
No I guess I'm not. But I am quite happy with Guy's correction. I
can still do things like:
(proclaim '(ftype (or (function (t list &rest t) list)
(function (t vector &rest t) vector))
remove))
And expect that a very good compiler would be able to deduce that the
call (remove 1 '#(1 2 3 4)) will return a vector. I think I will now
try to come up with a declaration for +.
-- Nick
∂22-Apr-86 0754 DLW@SCRC-STONY-BROOK.ARPA What is a compiler (vol. 63827) meets what are gensyms.
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 Apr 86 07:54:24 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 469050; Tue 22-Apr-86 10:46:43-EST
Date: Tue, 22 Apr 86 10:47 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: What is a compiler (vol. 63827) meets what are gensyms.
To: Fahlman@CMU-CS-C.ARPA, Gregor.pa@XEROX.ARPA
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12199819510.BABYL@C.CS.CMU.EDU>
Message-ID: <860422104731.7.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Fri, 18 Apr 1986 09:50 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
the dumper
has no business losing track of the EQ-ness of the symbols, whether or
not they are interned anywhere.
I agree with this (and this is what Moon said as well).
For purposes of the archives, though, I'd like to point out that if we
try to define this formally in the manual, we had better be careful.
Consider what happens if you run the dumper twice, creating two
independent files, and each run contains a certain uninterned symbol.
Then, in a new Lisp world, you load both files. If you require the
dumper to maintain EQness in this case, the dumper will be extremely
difficult to implement correctly. In fact, the same issues apply to
objects other than uninterned symbols, such as conses.
Also, we should keep in mind that the semantics of dump/load in the
presence of uninterned symbols clearly are not quite the same as the
semantics of print/read, despite the fact that the two operations are
roughly the same kind of thing.
∂22-Apr-86 0949 greek%bach.decnet@hudson.dec.com Proclaiming IGNORE
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 22 Apr 86 09:43:05 PST
Date: 22 Apr 86 09:21:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: Proclaiming IGNORE
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
I agree that proclaiming things about lexical variables is really opening
up a can of worms. I think we ought not.
- Paul
------
∂22-Apr-86 0949 greek%bach.decnet@hudson.dec.com A New &IGNORE keyword
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 22 Apr 86 09:43:32 PST
Date: 22 Apr 86 09:34:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: A New &IGNORE keyword
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Well, that'll teach me to send out mail without first reading all of
my new messages. Since I proposed the same thing as Dave Touretzky,
I must agree with him. Scott has a reasonable objection in that
all other &-keywords are punctuation, not actual placeholders. It's
not really the case that users can scan a lambda list and assume each
top-level item in the list grabs one of the arguments. That's certainly
not true for &REST, &BODY, or &ALLOW-OTHER-KEYS. I'm not really
bothered by an &-keyword that actually stands for an argument.
All in all, however, I agree that the IGNORE declaration is sufficient.
- Paul
------
∂22-Apr-86 0949 greek%bach.decnet@hudson.dec.com Ignoring bound variables.
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 22 Apr 86 09:42:36 PST
Date: 22 Apr 86 09:18:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: Ignoring bound variables.
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Well, how about we add a new ampersand keyword, &IGNORE ? We would
allow &IGNORE in lambda lists and in special forms like MULTIPLE-VALUE-BIND.
The keyword would mean "ignore exactly one argument in this position".
- Paul
------
∂22-Apr-86 1258 Moon@SCRC-STONY-BROOK.ARPA What is a compiler (vol. 63827) meets what are gensyms.
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 Apr 86 12:57:01 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 469458; Tue 22-Apr-86 15:16:52-EST
Date: Tue, 22 Apr 86 15:15 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: What is a compiler (vol. 63827) meets what are gensyms.
To: Common-Lisp@SU-AI.ARPA
In-Reply-To: <860418101724.8.DCP@FIREBIRD.SCRC.Symbolics.COM>
Message-ID: <860422151556.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 18 Apr 86 10:17 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
I think CLtL must be very explicit about what is preserved in the
load/dump process. The Symbolics implementation is EQUAL (often EQL)
for lists and EQL for everything else.
For the record, this is not exactly true. The Symbolics implementation
preserves EQness of objects within a single binary file output by the compiler;
this is a little stronger than PRINT/READ equality; perhaps it's equivalent to
PRINT/READ equality with *PRINT-CIRCLE* turned on and a giant PROGN wrapped
around the entire file.
The Symbolics implementation does not make lists that are EQUAL become EQ as
part of the load/dump process, contrary to what DCP implied. What it actually
does is to make constants within a compiled function or an unspecified group
of compiled functions that satisfy a certain predicate (which is approximately
EQUAL) become EQ, which is not quite the same.
I agree both that it would be good for the language specification to be very
explicit about what object relationships are preserved by loading and dumping,
and that this is very difficult.
∂22-Apr-86 1343 JAR@MC.LCS.MIT.EDU What is a compiler (vol. 63827) meets what are gensyms.
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 22 Apr 86 13:31:33 PST
Date: Tue, 22 Apr 86 16:32:57 EST
From: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
Subject: What is a compiler (vol. 63827) meets what are gensyms.
To: DLW@SCRC-QUABBIN.ARPA
cc: Common-Lisp@SU-AI.ARPA, Gregor.pa@XEROX.COM,
Fahlman@C.CS.CMU.EDU
In-reply-to: Msg of Tue 22 Apr 86 10:47 EST from Daniel L. Weinreb <DLW at SCRC-QUABBIN.ARPA>
Message-ID: <[MC.LCS.MIT.EDU].892135.860422.JAR>
Date: Tue, 22 Apr 86 10:47 EST
From: Daniel L. Weinreb <DLW at SCRC-QUABBIN.ARPA>
For purposes of the archives, though, I'd like to point out that if we
try to define this formally in the manual, we had better be careful.
Consider what happens if you run the dumper twice, creating two
independent files, and each run contains a certain uninterned symbol.
Then, in a new Lisp world, you load both files. If you require the
dumper to maintain EQness in this case, the dumper will be extremely
difficult to implement correctly. In fact, the same issues apply to
objects other than uninterned symbols, such as conses.
Also just for the archives: all these problems with EQness of gensyms
and locations could be solved if Common Lisp had a way to generate truly
unique names. The Aegis operating system has this feature, and it's
incredibly powerful: a "generate UID" system call will give you a bit
string (64 bits long) which is different from any other UID created at
any time by any other call to generate-UID on any machine running Aegis.
UID's are generated from the time of day and the serial number of the
CPU. Within the operating system they're used mostly to identify files,
processes, types, and other objects, but anyone is free to use them in
any circumstance which requires a unique token.
A very similar mechanism which more of you might be familiar with is the
"message id's" generated by mail systems, although I'm not aware of the
existence of any universally applied convention which really guarantees
uniqueness. One convention that would work would be if message-id's
began with the domain name of the machine which generated the message
id. (To make that really work, you'd have to make sure that every
machine had a domain name, and that different machines had different
names.)
I believe a mechanism like these could be adopted by a language and made
to work on arbitrary host operating systems and machines. If the
operating system has a way to determine the CPU's serial number, the
date & time of day (precisely), and a process ID, then it's
straightforward. (I leave out some detail that makes sure there won't
be collisions between names generated by different implementations or
machine types.) If a machine serial number isn't available, then
guaranteeing uniqueness is more difficult, but still possible; e.g. a
serial number could be generated when Lisp is installed on a particular
CPU (or file system).
E.g.:
(gensym) => #:860422104731.16.9112.JAR@MC.MIT.LCS.EDU
or whatever.
Given a mechanism like this, gensyms could in fact be interned, and so
could locations of conses and other mutable objects. Since the identity
of a gensym would be determined by its truly unique name, it could be
freely dumped and restored, or even printed and read, just like any
other symbol.
This may be a little too ambitious for Common Lisp, but I just wanted to
point out that the process of dumping and restoring gensyms is not prone
to inconsistencies, if gensyms really are unique.
(Maybe this could solve the package name collision problem, too...)
Jonathan
∂22-Apr-86 1406 Gregor.pa@Xerox.COM Re: What is a compiler (vol. 63827) meets what are gensyms.
Received: from XEROX.COM by SU-AI.ARPA with TCP; 22 Apr 86 13:53:47 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 22 APR 86 13:48:57 PST
Date: 22 Apr 86 13:48 PST
From: Gregor.pa@Xerox.COM
Subject: Re: What is a compiler (vol. 63827) meets what are gensyms.
In-reply-to: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>'s message of
Tue, 22 Apr 86 15:15 EST
To: Moon@SCRC-STONY-BROOK.ARPA
cc: Common-Lisp@SU-AI.ARPA
Message-ID: <860422-134857-1288@Xerox>
I think that making the language specification very explicit about
what object relationships are preserved by loading and dumping in
the way that DLW and Moon have suggested is what I was asking
for by sending my original message.
∂23-Apr-86 1513 snyder%hplsny@hplabs.ARPA with-output-to-string
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 23 Apr 86 15:13:07 PST
Received: from hplsny by hplabs.ARPA ; Wed, 23 Apr 86 08:32:23 pst
Received: by hplsny ; Wed, 23 Apr 86 07:12:18 pst
From: Alan Snyder <snyder%hplsny@hplabs.ARPA>
Message-Id: <8604231512.AA01394@hplsny>
Date: Wednesday, April 23, 1986 07:12:11
Subject: with-output-to-string
To: common-lisp@su-ai.ARPA
X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46
I haven't looked too hard, so perhaps I am missing something, but: What
function is used by WITH-OUTPUT-TO-STRING to create an output stream to an
existing string? MAKE-STRING-OUTPUT-STREAM does not take an argument.
-------
∂23-Apr-86 1847 RAM@C.CS.CMU.EDU with-output-to-string
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 23 Apr 86 18:46:55 PST
Received: ID <RAM@C.CS.CMU.EDU>; Wed 23 Apr 86 21:46:59-EST
Date: Wed, 23 Apr 1986 21:46 EST
Message-ID: <RAM.12201260719.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: Alan Snyder <snyder%hplsny@HPLABS.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: with-output-to-string
In-reply-to: Msg of 23 Apr 1986 07:12-EST from Alan Snyder <snyder%hplsny at hplabs.ARPA>
Date: Wednesday, 23 April 1986 07:12-EST
From: Alan Snyder <snyder%hplsny at hplabs.ARPA>
Re: with-output-to-string
I haven't looked too hard, so perhaps I am missing something, but: What
function is used by WITH-OUTPUT-TO-STRING to create an output stream to an
existing string? MAKE-STRING-OUTPUT-STREAM does not take an argument.
Not a Common Lisp function. It has been suggested by other people
that MAKE-STRING-OUTPUT-STREAM could take a optional arg which would
be a string with a fill-pointer.
Rob
∂23-Apr-86 1932 Moon@SCRC-STONY-BROOK.ARPA with-output-to-string
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 23 Apr 86 19:32:30 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 470760; Wed 23-Apr-86 22:31:52-EST
Date: Wed, 23 Apr 86 22:31 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: with-output-to-string
To: common-lisp@SU-AI.ARPA
In-Reply-To: <8604231512.AA01394@hplsny>
Message-ID: <860423223103.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wednesday, April 23, 1986 07:12:11
From: Alan Snyder <snyder%hplsny@hplabs.ARPA>
I haven't looked too hard, so perhaps I am missing something, but: What
function is used by WITH-OUTPUT-TO-STRING to create an output stream to an
existing string?
One that isn't documented.
MAKE-STRING-OUTPUT-STREAM does not take an argument.
In some implementations WITH-OUTPUT-TO-STRING does not work by calling
MAKE-STRING-OUTPUT-STREAM, since the former stream has dynamic extent
and the latter stream has indefinite extent.
The extension I think you are proposing is reasonable as an extension.
Do you propose that GET-OUTPUT-STREAM-STRING be allowed on that type
of stream?
∂25-Apr-86 1015 gls@THINK-AQUINAS.ARPA What is a compiler (vol. 63827) meets what are gensyms.
Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 25 Apr 86 10:15:23 PST
Received: from THINK-KATHERINE.ARPA by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 21402; Fri 25-Apr-86 13:19:42-EST
Date: Fri, 25 Apr 86 13:17 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: What is a compiler (vol. 63827) meets what are gensyms.
To: Moon@SCRC-STONY-BROOK.ARPA, Common-Lisp@SU-AI.ARPA
cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <860419181953.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <860425131707.1.GLS@THINK-KATHERINE.ARPA>
Date: Sat, 19 Apr 86 18:19 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
...
(DEFSETF BAR (#:G1890) (#:G1891) `(SET-BAR ,#:G1890 ,#:G1891)),
where the symbols that look the same are EQ ...
Tangential point: the above can be rendered in Common Lisp without
a tag line in English as follows:
(DEFSETF BAR (#1=#:G1890) (#2=#:G1891) `(SET-BAR ,#1# ,#2#)),
--Guy
∂25-Apr-86 2147 franz!fimass!jkf@kim.berkeley.edu :allow-other-keys
Received: from KIM.BERKELEY.EDU by SU-AI.ARPA with TCP; 25 Apr 86 21:47:25 PST
Received: by kim.berkeley.edu (5.45/1.12)
id AA03204; Fri, 25 Apr 86 21:48:20 PST
Resent-Date: Fri, 25 Apr 86 13:07:03 PST
Resent-From: franz!fimass!jkf@kim.berkeley.edu
Resent-Message-Id: <8604260548.AA03204@kim.berkeley.edu>
Received: from fimass by franz (5.5/3.14)
id AA01489; Fri, 25 Apr 86 20:49:27 PST
Received: by fimass (5.5/3.14)
id AA01541; Fri, 25 Apr 86 20:49:51 PST
Return-Path: <fimass!jkf>
Message-Id: <8604260449.AA01541@fimass>
Replied: Fri, 25 Apr 86 20:49:16 PST
Replied: "franz!rfr (Robert Rorschach) cl"
id AA00976; Fri, 25 Apr 86 13:07:55 PST
id AA00637; Fri, 25 Apr 86 13:07:03 PST
Date: Fri, 25 Apr 86 13:07:03 PST
From: franz!fimass!franz!rfr@kim.berkeley.edu (Robert Rorschach)
To: cl@kim.berkeley.edu
Subject: :allow-other-keys
Resent-To: common-lisp@su-ai.arpa
Sender: franz!fimass!jkf@kim.berkeley.edu
The way CLtL is written, this keyword's behaviour is nonstandard.
(foo :allow-other-keys nil :allow-other-keys t),
according to the letter, allows other keys. With all other keyword
arguments, only the first occurrence of the keyword counts.
Does anyone know whether this anomaly is intentional?
It seems like it could be an accident of phrasing.
∂26-Apr-86 0530 nttlab!umemura@su-shasta.arpa SOFTWARE-TYPE & SOFTWARE-VERSION
Received: from SU-SHASTA.ARPA by SU-AI.ARPA with TCP; 26 Apr 86 05:30:22 PST
Received: by su-shasta.arpa with TCP; Sat, 26 Apr 86 05:30:15 pst
Received: by ntt.junet (4.12/4.7JC-7) CHAOS with CHAOS-MAIL
id AA14901; Sat, 26 Apr 86 15:47:38 jst
Date: Sat, 26 Apr 86 15:47:38 jst
From: nttlab!umemura@su-shasta.arpa (Kyoji UMEMURA)
Message-Id: <8604260647.AA14901@ntt.junet>
To: Common-lisp@SU-AI.ARPA
Subject: SOFTWARE-TYPE & SOFTWARE-VERSION
Why does SOFTWARE-VERSION returns not number, but string?
If we cannot compare two versions and cannot determine which is
newer, why does SOFTWARE-TYPE exist?
It is the same about MACHINE-TYPE and MACHINE-VERSION.
(I am a newcomer. Sorry, if it is already discussed)
Kyoji Umemura (nttlab)
∂26-Apr-86 1030 pyramid!bein@SUN.COM funcall
Received: from SUN.COM by SU-AI.ARPA with TCP; 26 Apr 86 10:30:13 PST
Received: from sun.uucp by sun.com (3.2-/SMI-3.0)
id AA08705; Sat, 26 Apr 86 10:17:53 PST
Received: by sun.uucp (1.1/SMI-2.0)
id AA09632; Sat, 26 Apr 86 10:20:42 PST
Received: by pyramid (4.12/3.14)
id AA21984; Sat, 26 Apr 86 09:43:24 pst
Date: 26 Apr 1986 09:19-PST
From: David Bein <pyramid!bein@SUN.COM>
Subject: funcall
To: common-lisp@su-ai.arpa
Message-Id: <514919994/bein@pyramid>
Suppose we have the following code:
(defun mumble (a)
(flet ((mumble (a) (print "internal-mumble")))
(when (something a) (funcall 'mumble a))
(print "external-mumble")
Is it 100% legal to pass funcall a symbol? Most implementations I
have seen allow this although the manual tends to imply that the
thing being funcall'ed must be a "function". Notice that I am
carefully trying avoid what exactly is a function question which
others have raised recently.
Is a compiler justified in simply turning this into a call to mumble
as if it had been written as (mumble a) in the first place?
If so, which mumble should be apparent? If not, is a compiler justified
in turning the form into:
(funcall (symbol-function 'mumble) a) ?
Another related matter, suppose we change the funcall arg to
#'mumble --> (function mumble). Is it clearly the case then that
the mumble which is apparent is the inner one?
--David
p.s. Sorry if this question has been answered previously..
∂26-Apr-86 1232 FAHLMAN@C.CS.CMU.EDU SOFTWARE-TYPE & SOFTWARE-VERSION
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 26 Apr 86 12:32:07 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 26 Apr 86 15:33:09-EST
Date: Sat, 26 Apr 1986 15:33 EST
Message-ID: <FAHLMAN.12201979095.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: nttlab!umemura@λsu-shasta (Kyoji UMEMURA)λ
Cc: common-lisp@SU-AI.ARPA
Subject: SOFTWARE-TYPE & SOFTWARE-VERSION
There are really two uses for Software-Type, Software-Version,
Machine-Type, and Machine-Version. The more common use is so that a
Lisp user can precisely identify exactly what configuration he is
running on. This is especially useful in reporting bugs, reporting
benchmarks, etc. In an environment with many machines and many Lisp
versions, it is very difficult for the maintainers to do anything when a
bug report comes in without this precise information. For this purpose,
all that is required is that the information be precise, unambigious,
and human-readable.
The other use is in portable programs that may want to adjust their
behavior according to the kind of environment in which they are running.
The way a certain display is set up, for example, might be different
according the machine type, the machine version, the operating system
type, and the operating system version. It would be useful for the
version calls to return numbers in this case, rather than strings, so
that Lisp code could say things like
(if (> (software-version) 100)
(new-style-stuff)
(old-style-stuff))
However, it was observed that the use of a number here is not general
enough to handle all the different version-numberins schemes used by
diferent manufacturers. Some use fixnums, some use numbers like 1.5 and
4.2, some use letter-number combinations like G12b, some use name-number
combiantions, like "internal 27.3". The real problem is that software
releases are often not linearly ordered, but form a complex lattice,
with some version being split off, developing independently through
several versions, and then being merged back into the mainstream.
So we felt that a call like this, to be universal, has to return an
aribtrary string that the user can examine and that software can compare
in a system-specific way. If a given system uses a simple integer
numbering scheme, the user can just call Parse-Integer to get the
numerical value.
-- Scott
∂26-Apr-86 1239 RAM@C.CS.CMU.EDU funcall
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 26 Apr 86 12:38:55 PST
Received: ID <RAM@C.CS.CMU.EDU>; Sat 26 Apr 86 15:39:53-EST
Date: Sat, 26 Apr 1986 15:39 EST
Message-ID: <RAM.12201980322.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: David Bein <pyramid!bein@SUN.COM>
Cc: common-lisp@SU-AI.ARPA
Subject: funcall
In-reply-to: Msg of 26 Apr 1986 12:19-EST from David Bein <pyramid!bein at SUN.COM>
Date: Saturday, 26 April 1986 12:19-EST
From: David Bein <pyramid!bein at SUN.COM>
Re: funcall
Suppose we have the following code:
(defun mumble (a)
(flet ((mumble (a) (print "internal-mumble")))
(when (something a) (funcall 'mumble a))
(print "external-mumble")
Is it 100% legal to pass funcall a symbol? Most implementations I
have seen allow this although the manual tends to imply that the
thing being funcall'ed must be a "function".
It is pretty clear that passing a symbol to FUNCALL is legal.
Although it doesn't say so in the funcall description, it is
explicitly allowed in APPLY. It would be pretty silly not to apply
the same rule to FUNCALL. I would say that regardless of whether a
symbol is a function or not, it is legal to pass a symbol to FUNCALL.
Is a compiler justified in simply turning this into a call to mumble
as if it had been written as (mumble a) in the first place?
No, as in APPLY, calling a symbol calls the global definition.
Another related matter, suppose we change the funcall arg to
#'mumble --> (function mumble). Is it clearly the case then that
the mumble which is apparent is the inner one?
Yes, FUNCTION evaluates a "functional expression" in the lexical
environment at the point of call.
Rob
∂26-Apr-86 1245 FAHLMAN@C.CS.CMU.EDU :allow-other-keys
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 26 Apr 86 12:45:04 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 26 Apr 86 15:45:55-EST
Date: Sat, 26 Apr 1986 15:45 EST
Message-ID: <FAHLMAN.12201981424.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: franz!fimass!franz!rfr@λkim.berkeley.edu (Robert Rorschach)λ
Cc: common-lisp@SU-AI.ARPA
Subject: :allow-other-keys
In-reply-to: Msg of 25 Apr 1986 16:07-EST from franz!fimass!franz!rfr at kim.berkeley.edu (Robert Rorschach)
I don't think it ever occurred to anyone that there might be two
occurrences of :allow-other-keys among a function's arguments,
especially with conflicting values. We should probably just declare
this situation to be an error. If we don't do that, we should rule that
the leftmost occurrence of this keyword governs, since that is
consistent with what other keywords do and, I suspect, is what most
existing compilers and interpreters do.
-- Scott
∂26-Apr-86 1823 Pavel.pa@Xerox.COM macro-let and *macroexpand-hook*
Received: from XEROX.COM by SU-AI.ARPA with TCP; 26 Apr 86 18:18:09 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 26 APR 86 18:19:07 PST
Date: 26 Apr 86 18:12 PST
From: Pavel.pa@Xerox.COM
Subject: macro-let and *macroexpand-hook*
To: Common-Lisp@SU-AI.ARPA
Message-ID: <860426-181907-1025@Xerox>
Well, I've looked through the archives and I've read through the silver
book but I still can't tell whether or not expansion of macro-let'ed
macros is supposed to use *macroexpand-hook* or not. It is clear that
the environment argument passed to macroexpand-1 must contain those
lexically-defined macros, but should *macroexpand-hook* be prepared to
deal with them?
It seems like the right thing is that *macroexpand-hook* should, indeed,
be called, but it makes it harder to write a portable memoization
facility; at least one such facility, in the Spice Lisp code, assumes
that macro-function will retrieve the expansion function for any macro
it is asked to deal with.
Pavel
∂26-Apr-86 1833 Pavel.pa@Xerox.COM macro-let and *macroexpand-hook*
Received: from XEROX.COM by SU-AI.ARPA with TCP; 26 Apr 86 18:32:52 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 26 APR 86 18:30:58 PST
Date: 26 Apr 86 18:12 PST
From: Pavel.pa@Xerox.COM
Subject: macro-let and *macroexpand-hook*
To: Common-Lisp@SU-AI.ARPA
Message-ID: <860426-183058-1028@Xerox>
Well, I've looked through the archives and I've read through the silver
book but I still can't tell whether or not expansion of macro-let'ed
macros is supposed to use *macroexpand-hook* or not. It is clear that
the environment argument passed to macroexpand-1 must contain those
lexically-defined macros, but should *macroexpand-hook* be prepared to
deal with them?
It seems like the right thing is that *macroexpand-hook* should, indeed,
be called, but it makes it harder to write a portable memoization
facility; at least one such facility, in the Spice Lisp code, assumes
that macro-function will retrieve the expansion function for any macro
it is asked to deal with.
Pavel
∂27-Apr-86 1152 RAM@C.CS.CMU.EDU macro-let and *macroexpand-hook*
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 27 Apr 86 11:52:46 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Sun 27 Apr 86 14:53:50-EDT
Date: Sun, 27 Apr 1986 14:53 EDT
Message-ID: <RAM.12202223167.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: Pavel.pa@XEROX.COM
Cc: Common-Lisp@SU-AI.ARPA
Subject: macro-let and *macroexpand-hook*
In-reply-to: Msg of 26 Apr 1986 21:12-EST from Pavel.pa at Xerox.COM
I believe that there wouldn't be any problem if MACRO-FUNCTION
took an optional environment arg. Of course, it would be illegal to
set the value of a lexical macro.
Rob
∂27-Apr-86 1544 KMP@SCRC-STONY-BROOK.ARPA SOFTWARE-TYPE, SOFTWARE-VERSION, ...
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 27 Apr 86 15:43:58 PDT
Received: from HUMMINGBIRD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 473377; Sun 27-Apr-86 18:43:05-EDT
Date: Sun, 27 Apr 86 18:44 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: SOFTWARE-TYPE, SOFTWARE-VERSION, ...
To: Fahlman@C.CS.CMU.EDU
cc: Common-Lisp@SU-AI.ARPA
References: <FAHLMAN.12201979095.BABYL@C.CS.CMU.EDU>,
<8604260647.AA14901@ntt.junet>
Message-ID: <860427184404.3.KMP@HUMMINGBIRD.SCRC.Symbolics.COM>
While we're on the subject, let me say that my experience in trying to port
Macsyma has suggested that we have not been specific enough in the description
of what SOFTWARE-TYPE should return for it to be very useful even in the range
of things for which I think it was intended. For example,...
LISP-IMPLEMENTATION-TYPE
Not enough examples are given to figure out what this might return.
I believe this should have been defined as the vendor. It's dumb for
a 3600 to respond "Zetalisp" since the trend on the 3600 is for Zetalisp
to be supported as a Common Lisp compatibility thing and not vice versa.
Because the manual cites the example of "Zetalisp", it's hard to imagine
us not returning that value. I still think it should return "Symbolics".
Also, it doesn't say whether the word "lisp" will get included. It leaves
one open to return "Franz" or "Lucid".
It would have been better to actually give an example sentence into which
the result of functions like this item should have fit. eg,
(FORMAT T "~&This is the ~A implementation of Common Lisp."
(LISP-IMPLEMENTATION-TYPE))
LISP-IMPLEMENTATION-VERSION
Some lisps return something fairly short so you could imagine doing:
(FORMAT T "~&This is Macsyma in ~A ~A."
(LISP-IMPLEMENTATION-TYPE) (LISP-IMPLEMENTATION-VERSION))
but it isn't suggested that this might be something you'd want to do so
the 3600 Release 6 implementation I'm running returns something like:
"Release 6.1, System 271.216, Hardcopy 46.34, Zmail 107.25, Experimental Something 12.36, IP-TCP 29.13, SCRC 5.26, Something Else 60.0, Experimental Something More 389.0, microcode IFU-IO4-XSQ-COL-MIC 353, FEP 127, FEP0:>v127-lisp.flod(4), FEP0:>v127-loaders.flod(4), FEP0:>v127-i-cache.flod(29), FEP0:>v127-debug.flod(10), FEP0:>v127-info.flod(4)"
and it would look really yucky to use that format string because of the
line over-run that would result.
MACHINE-TYPE
This is one of the only things that I think is adequately constrained.
MACHINE-VERSION
This isn't very well-constrained. For example, I can't imagine writing
(FORMAT T "This is Common Lisp on a ~A ~A"
(MACHINE-TYPE) (MACHINE-VERSION))
even with the examples you've given. eg, it might come out as:
"This is Common Lisp on a DEC PDP-10 KL10, microcode 9"
In other words, isn't "KL10" part of the machine-type, not the version?
Maybe it's really well-formed -- I've just never seen it referred to that way.
Again, saying in the documentation that operations like the FORMAT I've just
given should produce meaningful, non-cluttered output would be very handy.
MACHINE-INSTANCE
It was dumb given that any of these operations can return NIL if it doesn't
have something meaningful to return to say that this could return either a
serial number or a host-id. We should have had a HOST-NAME and a
MACHINE-UNIQUE-ID. The former should have returned the host name for the purpose
of things like
(FORMAT T "~&From: ~A@~A~%"
(USER-ID) ;we forgot to include this but it should be added
(HOST-NAME))
SOFTWARE-TYPE
It doesn't indicate at what level the supporting software is. eg, your examples
seem to imply that you want the operating system type. What if LUCID had a lisp
that ran under VMS. Would you want "VMS", "DEC", or "LUCID"? If you can't be specific
about this, then how can you expect it to be meaningfully used in portable code?
We return "Lisp Machine", which seems pretty random, but I'm not sure what we could
do that is better.
SOFTWARE-VERSION
This suffers from the same vagueness problems. We return
"Pre-release Symbolics Common Lisp" in Release 6. What can I do with this?
I can write:
(FORMAT T "~&You are being supported by ~A ~A"
(SOFTWARE-TYPE) (SOFTWARE-VERSION))
Can you imagine how well this will port? On our implementation, this will
produce:
You are being supported by Lisp Machine Pre-release Symbolics Common Lisp.
which looks pretty dumb... and that's using it in the least committal way
possible. Imagine if I wanted to include it into any other output in a more
specific way.
SHORT-SITE-NAME
LONG-SITE-NAME
Nothing specifies whether "site" means "host" or "community". The Symbolics
community distinguishes these terms. A site to us would be like "MIT" or
the "MIT AI Lab". A host is a specific machine at a site. I'm told by friends
at DEC that (SHORT-SITE-NAME) is treated more like "host". Without standardizing
on this term, the description is fairly meaningless.
I was amazingly disappointed when I found out how poorly these were specified
and how little-useful they were going to be in portable code. The only way I
can think to use this information in a portable way is to do:
(FORMAT T "Random debugging data:~{~@[~%~1{~A: ~A~}~]~}"
(MAPCAR #'(LAMBDA (X) (LET ((Y (FUNCALL X))) (IF Y (LIST X Y))))
'(LISP-IMPLEMENTATION-TYPE LISP-IMPLEMENTATION-VERSION ...)))
That's pretty weak.
∂28-Apr-86 0745 greek%bach.decnet@hudson.dec.com Environment Query Functions.
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 28 Apr 86 07:44:51 PDT
Date: 28 Apr 86 10:36:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: Environment Query Functions.
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
I think the watchword is "short and sweet" as far as the environment
query functions are concerned. Here's what we do for VAX LISP.
LISP-IMPLEMENTATION-TYPE is "VAX LISP".
LISP-IMPLEMENTATION-VERSION is something like "V2.0".
MACHINE-TYPE is the machine name, like "DEC VAX 11/780" "DEC VAXstation II".
MACHINE-VERSION is tough to call, so we return the SID register, which
uniquely identifies the CPU. Not so great.
MACHINE-INSTANCE is setable by the system manager/user.
SOFTWARE-TYPE is "VMS" or "ULTRIX".
SOFTWARE-VERSION is whatever the operating system says its version is.
SHORT-SITE-NAME & LONG-SITE-NAME is setable by the system manager/user.
In particular, we felt in the three cases where it's setable that we
just couldn't guess what it ought to be.
- Paul
------
∂28-Apr-86 0901 snyder%hplsny@hplabs.ARPA Re: with-output-to-string
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 28 Apr 86 09:00:15 PDT
Received: from hplsny by hplabs.ARPA ; Mon, 28 Apr 86 09:01:04 pdt
Received: by hplsny ; Mon, 28 Apr 86 09:00:47 pdt
From: Alan Snyder <snyder%hplsny@hplabs.ARPA>
Message-Id: <8604281600.AA00138@hplsny>
Date: Monday, April 28, 1986 09:00:36
Subject: Re: with-output-to-string
To: Moon@SCRC-STONY-BROOK.ARPA
Cc: common-lisp@su-ai.ARPA
In-Reply-To: Your message of 23-Apr-86 22:31:00
X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46
In some implementations WITH-OUTPUT-TO-STRING does not work by calling
MAKE-STRING-OUTPUT-STREAM, since the former stream has dynamic extent
and the latter stream has indefinite extent.
That makes sense, but the ability for a user to create an output stream
to an existing string would still be useful.
The extension I think you are proposing is reasonable as an extension.
Do you propose that GET-OUTPUT-STREAM-STRING be allowed on that type
of stream?
That is not required, but would seem useful.
-------
∂28-Apr-86 1426 lab@rochester.arpa Readtables
Received: from ROCHESTER.ARPA by SU-AI.ARPA with TCP; 28 Apr 86 14:26:40 PDT
Received: from ur-seneca.rochester.arpa (ur-seneca) by ur-cayuga.rochester.arpa id AA09597 (4.12w); Mon, 28 Apr 86 13:27:05 edt
Received: by ur-seneca.rochester.arpa id AA09514 (4.12w); Mon, 28 Apr 86 17:27:21 edt
Message-Id: <8604282127.9514@ur-seneca.rochester.arpa>
Date: Mon, 28 Apr 86 17:27:21 edt
From: Brad Miller(Tech. Ops. Mgr) <lab@rochester.arpa>
To: common-lisp@su-ai.arpa
Subject: Readtables
I have a question about readtables. Forgive me if this is an already
discussed topic.
I have a program, in package FOO. It sets a macro character via
(set-macro-character) using the default readtable.
Problem: now all programs on the machine will call the macro function
regardless of whether they USE the package.
One solution: do (set-macro-character char function nil (setq my-readtable
(copy-readtable nil)))
which will put it in a readtable "separate" from everyone elses. Problem:
have no way of determining when the "new" readtable should be used. Either have
to have separate read loop just for this program, or do something else
crufty like recognize the current default package isn't the one we want.
It seems, at first blush, the desired feature would be to somehow
associate readtables with packages. That
is, if the readtable I use is associated with my current package, my current
problem is solved. This seems pretty general. Hierarchical packages would also
have hierarchical readtables. You could still change readtables while IN a
package, but the big win is on most machines, making the package with your
program in it (or a child of that one) the default means your macro is in
effect. Packages which do not inherit from your special one won't know about
your macro.
Thanks for your help,
Brad Miller
Brad Miller ARPA: lab@rochester.arpa UUCP:rochester!lab
(also miller@rochester for grad student stuff)
Title: CS Technical Operations Manager
Snail: University of Rochester Computer Science Department
617 Hylan Building Rochster, NY 14627
∂28-Apr-86 1703 GJC@MC.LCS.MIT.EDU Readtables
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 28 Apr 86 16:59:45 PDT
Date: Mon, 28 Apr 86 20:01:23 EDT
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Subject: Readtables
To: lab@ROCHESTER.ARPA
cc: common-lisp@SU-AI.ARPA
In-reply-to: Msg of Mon 28 Apr 86 17:27:21 edt from Brad Miller(Tech. Ops. Mgr) <lab at rochester.arpa>
Message-ID: <[MC.LCS.MIT.EDU].897993.860428.GJC>
NIL and the MIT/LMI-LISPM system had just such a mechanism, named readtables.
(GET-READTABLE-NAMED "Maclisp") would be analogous to (FIND-PACKAGE "Maclisp").
The mechanism was invoked by the good-old file mode line:
;;;-*-mode:lisp;readtable:maclisp;base:10-*-
I suppose we will have to wait for the gods-on-high, er, I mean Symbolics REL7,
before any discussion of "environment issues" can progress however. We
all wait, breathless.
∂28-Apr-86 1838 lab@rochester.arpa Readtables
Received: from ROCHESTER.ARPA by SU-AI.ARPA with TCP; 28 Apr 86 18:38:24 PDT
Received: from ur-seneca.rochester.arpa (ur-seneca) by ur-cayuga.rochester.arpa id AA11693 (4.12w); Mon, 28 Apr 86 17:37:52 edt
Received: by ur-seneca.rochester.arpa id AA13994 (4.12w); Mon, 28 Apr 86 21:38:33 edt
Message-Id: <8604290138.13994@ur-seneca.rochester.arpa>
Date: Mon, 28 Apr 86 21:38:33 edt
From: Brad Miller(Tech. Ops. Mgr) <lab@rochester.arpa>
To: GJC@MC.LCS.MIT.EDU
Cc: lab@rochester.arpa, common-lisp@SU-AI.ARPA
In-Reply-To: "George J. Carrette"'s message of Mon, 28 Apr 86 20:01:23 EDT
Subject: Readtables
So you feel this is an environment issue rather than a language design
issue? I would think the need and the solution (at least a proposed
solution of formally folding it into packages) could be addressed at
the language level: gives us portability of code; forces all vendors
to address the problem, and other nice side effects...
Brad Miller
∂29-Apr-86 2139 RPG add to mailing list
∂29-Apr-86 2025 MATHIS@USC-ISIF.ARPA add to mailing list
Received: from USC-ISIF.ARPA by SU-AI.ARPA with TCP; 29 Apr 86 20:25:45 PDT
Date: 29 Apr 1986 20:11-PDT
Sender: MATHIS@USC-ISIF.ARPA
Subject: add to mailing list
From: MATHIS@USC-ISIF.ARPA
To: RPG@SU-AI.ARPA
Cc: Fahlman@C.CS.CMU.EDU, Hadden@HI-MULTICS.ARPA
Cc: Mathis@USC-ISIF.ARPA
Message-ID: <[USC-ISIF.ARPA]29-Apr-86 20:11:02.MATHIS>
Dick,
Please add George Hadden (Hadden at HI-MULTICS) to the Common
Lisp mailing list. He is doing a Common Lisp implementation for
Honeywell. His phone number is (612)541-6833. He also expressed
an interest in the archives; maybe you or Scott can advise him.
Thanks, Bob
∂30-Apr-86 0512 somewhere!yuasa@kurims.kurims.kyoto-u.junet
Received: from SU-SHASTA.ARPA by SU-AI.ARPA with TCP; 30 Apr 86 05:12:32 PDT
Received: by su-shasta.arpa with TCP; Wed, 30 Apr 86 05:12:33 pdt
Received: by ntt.junet (4.12/4.7JC-7) CHAOS with CHAOS-MAIL
id AA19453; Wed, 30 Apr 86 17:22:38 jst
From: yuasa@kurims.kurims.kyoto-u.junet
Received: by kurims.kyoto-u.junet (2.0/4.7)
id AA00467; Wed, 30 Apr 86 18:19:24 pdt
Date: Wed, 30 Apr 86 18:19:24 pdt
Message-Id: <8605010119.AA00467@kurims.kyoto-u.junet>
To: nttlab!Common-Lisp@SU-AI
The following is the text, verbatim, of the other handout I made
available this past Monday at the Common Lisp meeting.
----------------------------------------------------------------------
Corrections to first printing of Common Lisp: The Language
Thanks to the many people who noticed these problems, and
especially to Dr. Masayuki Ida, who found over fifty of them.
-- Guy Steele, December 1985
.........
87 Rewrite the second sentence in the description of FUNCTION as
follows: "In particular, if fn is a symbol, then the functional
definition of that name is returned, which is that established by the
innermost lexically enclosing FLET, LABELS, or MACROLET construct, if
there is one, or else the global functional definition of the symbol
(see SYMBOL-FUNCTION)."
.........
Is this sentense really intended to require that (FUNCTION FOO)
in the body of (MACROLET ((FOO <args> . <body>)) ...) should return
the macroexpansion function of the local macro FOO? For example,
should
(FUNCALL (MACROLET ((FOO (X) `(LIST ,X ,X)))
(FUNCTION FOO))
'(FOO (BAR)))
evaluate to (LIST (BAR) (BAR)) ? If this is really the case, then
what are the merits of this mechanism? For your information, Kyoto
Common Lisp just ignores local macro definitions when evaluating FUNCTION
special forms. The version of Spice Lisp which I received in April 1985
causes an error if <symbol> in (FUCNTION <symbol>) names a local macro.
-- Taiichi
(one of the implementors of Kyoto Common Lisp)
(nttlab!kurims!yuasa@su-shasta.arpa)
∂30-Apr-86 0603 DCP@SAPSUCKER.SCRC.Symbolics.COM Readtables
Received: from [192.10.41.223] by SU-AI.ARPA with TCP; 30 Apr 86 06:03:05 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 13169; Wed 30-Apr-86 09:01:02 EDT
Date: Wed, 30 Apr 86 08:59 EDT
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: Readtables
To: George J. Carrette <GJC@MC.LCS.MIT.EDU>,
Brad Miller <lab@ROCHESTER.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <[MC.LCS.MIT.EDU].897993.860428.GJC>,
<8604290138.13994@ur-seneca.rochester.arpa>
Message-ID: <860430085956.3.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Mon, 28 Apr 86 20:01:23 EDT
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
NIL and the MIT/LMI-LISPM system had just such a mechanism, named readtables.
(GET-READTABLE-NAMED "Maclisp") would be analogous to (FIND-PACKAGE "Maclisp").
The mechanism was invoked by the good-old file mode line:
;;;-*-mode:lisp;readtable:maclisp;base:10-*-
I suppose we will have to wait for the gods-on-high, er, I mean Symbolics REL7,
before any discussion of "environment issues" can progress however. We
all wait, breathless.
Give us all a break, George. You used to, and possibly still do but I
can't tell since your mail originates from MIT, work for one of
Symbolics' comercial competitors whose system has the same roots as
Symbolics'. The reason Symbolics people ask others to be careful about
the distinction between language and programming environment is because
we think about it every day as part of our work. People at LMI, Xerox
and others probably do too. People at Lucid (possibly the other end of
the spectrum) probably don't because their current business is to
produce a powerful compiler. This also has nothing to do with releases.
We need to decide what is part of Common Lisp, the Language. With the
multidimensional designations I've seen for the ISO Common Lisp, we need
to be even more specific. Not only do we need to know if it is language
or environment, but we have to know what level (substrate, basic,
advanced, toplevel, etc) of each it is.
Date: Mon, 28 Apr 86 21:38:33 edt
From: Brad Miller(Tech. Ops. Mgr) <lab@rochester.arpa>
So you feel this is an environment issue rather than a language design
issue? I would think the need and the solution (at least a proposed
solution of formally folding it into packages) could be addressed at
the language level: gives us portability of code; forces all vendors
to address the problem, and other nice side effects...
A few questions: Why should readtables be folded into packages?
Consider the following, not too far-fetched, duple:
- What's wrong with using a prolog readtable with the USER
package? The implication is that the user is writing code for the
USER package, but the code is being written in prolog!
- What's wrong with using a CL readtable in the PROLOG-USER package
(which normally uses a prolog read-table)? The implication here is
that a prolog user is writing code, but is writing it in Common Lisp.
The current main differences between the interfaces to readtable and
packages that I can think of off the top of my head are the following.
(1) Packages are globally named and seldom stored in variables, whereas
readtables are not generally named but are stored in variables.
(1a) To find a package one generally uses (find-package <name>). To
find a readtable one generally uses *foo-readtable*.
(2) Packages cannot be copied for the purpose of modification.
Readtables can, and this mechanism exists.
(3) Because of (1) and (2), packages determine the identity of symbols
for the lifetime of the incarnation of the Lisp in which they
exist (which includes saving worlds and rebooting, etc). Symbols
are rather permanent in this sense. Readtables, on the other hand,
determine how TEXT is parsed into LISP. By changing the readtable
you can alter the parsing. There aren't any "reasonable" ways to
meaningfully alter packages to get similar effects.
(4) If packages did not have names, we would be writing symbols as
*foo-package*:print-name instead of foo:print-name. But since this
IS THE TEXT it is divorced from the readtable. We currently don't
have a way to say #@Maclisp ...maclisp-form....
(5) The effects of in-package are the dynamic extent of the load
operation of the file (see page 183). I couldn't find an
equivalent thing for *readtable*.
I personally don't have any problems with (1), (2) or (3). I think the
current readtable paradigm is sufficient and adequate.
Regarding (5), I will cast a vote that the effects of
(eval-when (eval load compile) (setq *readtable* *my-readtable*))
have the dynamic extent of the load operation in the same way
in-package does. I will also cast a vote that a form should be
considered to capture the above notion.
Regarding (4), we need to decide if we want to add some functionality to
readtables that are parallel to packages. Do we want to globally name
readtables? Do we want an in-band way to change the readtable for one
or more forms? The package system has its roots in experience, and it
still has problems. Do people have enough experience with readtables to
feel comfortable about any of these issues?
∂30-Apr-86 0726 NGALL@G.BBN.COM Re: FUNCTION and MACROLET
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 30 Apr 86 07:26:35 PDT
Date: 30 Apr 1986 10:28-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: FUNCTION and MACROLET
From: NGALL@G.BBN.COM
To: nttlab!kurims!yuasa@SU-SHASTA.ARPA
Cc: Common-Lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]30-Apr-86 10:28:34.NGALL>
In-Reply-To: <8605010119.AA00467@kurims.kyoto-u.junet>
Date: Wed, 30 Apr 86 18:19:24 pdt
From: yuasa@kurims.kurims.kyoto-u.junet
To: nttlab!Common-Lisp@SU-AI
Message-ID: <8605010119.AA00467@kurims.kyoto-u.junet>
87 Rewrite the second sentence in the description of FUNCTION as
follows: "In particular, if fn is a symbol, then the functional
definition of that name is returned, which is that established by the
innermost lexically enclosing FLET, LABELS, or MACROLET construct, if
there is one, or else the global functional definition of the symbol
(see SYMBOL-FUNCTION)."
Is this sentense really intended to require that (FUNCTION FOO)
in the body of (MACROLET ((FOO <args> . <body>)) ...) should return
the macroexpansion function of the local macro FOO?
No. (FUNCTION FOO) in the body of a (MACROLET ((FOO... should return
"an object representing a ... macro ... it is an error to attempt to
invoke the object as a function" (cf. SYMBOL-FUNCTION, pg. 90).
(FUNCALL (MACROLET ((FOO (X) `(LIST ,X ,X)))
(FUNCTION FOO))
'(FOO (BAR)))
Thus this example is not legal common lisp.
If this is really the case, then what are the merits of this
mechanism?
The behavior of FUNCTION when given the name of a local function/macro
should be consistent with its behavior when given the name of a global
function/macro, and the behavior of FUNCTION when given the name of a
global function/macro/special-form should be consistent with the
behavior of SYMBOL-FUNCTION when given the name of a global
function/macro/special-form. I think this is what Guy's proposed
clarification is trying to get across.
-- Taiichi
(one of the implementors of Kyoto Common Lisp)
(nttlab!kurims!yuasa@su-shasta.arpa)
--------------------
-- Nick
∂30-Apr-86 0927 lab@rochester.arpa Readtables
Received: from ROCHESTER.ARPA by SU-AI.ARPA with TCP; 30 Apr 86 09:26:59 PDT
Received: from ur-seneca.rochester.arpa (ur-seneca) by ur-cayuga.rochester.arpa id AA01089 (4.12w); Wed, 30 Apr 86 08:22:51 edt
Received: by ur-seneca.rochester.arpa id AA29900 (4.12w); Wed, 30 Apr 86 12:01:53 edt
Message-Id: <8604301601.29900@ur-seneca.rochester.arpa>
Date: Wed, 30 Apr 86 12:01:53 edt
From: Brad Miller(Tech. Ops. Mgr) <lab@rochester.arpa>
To: DCP@SCRC-QUABBIN.ARPA
Cc: GJC@MC.LCS.MIT.EDU, lab@rochester.arpa, common-lisp@SU-AI.ARPA
In-Reply-To: David C. Plummer's message of Wed, 30 Apr 86 08:59 EDT
Subject: Readtables
OK, let me redefine the original problem. Maybe this 'makes' it an
environment issue. Given that I have two or more programs under
development. Why should my defining a macro in one program have an
effect on the other? Currently it does because I have changed the
default readtable. Changing my package from one program's package to
the other program's package used to be sufficent for a 'context
switch' but now I also have to change readtables. What I was
suggesting is that the readtable was defined inside of a package, and
in some sense should be part of that package. i.e. if I change the
default readtable, I am really changeing the default FOR A PACKAGE.
Packages are very much like contexts. If I have a package that has an
ancestor, it should inherit the default readtable from that ancestor.
If I redefine the default readtable, I do it locally, not to the
ancestor (unless I do so explicitly).
Note that this is just a change to the DEFAULT readtable mechanism,
and does not constitute a change to other mechanisms already present.
If a prlog user wants to write code in the USER package, that's fine,
and he can use the prolog readtable. When he changes to the CL
package, he shouldn't still be stuck with the prolog readtable,
however, (and have to do something explicit to change it).
Now you could argue that I shouldn't be altering the default readtable
at all, and changing the readtable depending on the task involved
(rather than just changing packages, or whatever). But consider this,
given two programs in package A and B, where A has a macro bound to
#\! and B does not, this is what would be nice:
(pkg-goto 'USER)
<invoking !foo would mean !foo - no macro invocation,
invoking A:!foo WOULD invoke the macro>
(pkg-goto 'A)
<invoking !foo would invoke the macro
invoking B:!foo would NOT>
Note that this does not imply any change to the way readtables or
referenced. If mI want to talk about a readtable explitily, I may
still want to use variable, but each package might have associated
with it a variable *default-readtable*, and it is inheritable if it is
defined.
Now I will totally agree that whether this is a
basic/advanced/toplevel etc. issue is unclear to me. All I am stating
is that I think there is a need to do this sort of thing; it would be
nice that if everyone who said they supported CL supported this.
Also, does anyone else think similar thoughts, or am I out in left
field, since there are other existing easy ways to do this sort of
thing, and/or it has no business being in the CL language?
Brad Miller ARPA: lab@rochester.arpa UUCP:rochester!lab
(also miller@rochester for grad student stuff)
Title: CS Technical Operations Manager
Snail: University of Rochester Computer Science Department
617 Hylan Building Rochster, NY 14627
∂30-Apr-86 1025 DCP@SAPSUCKER.SCRC.Symbolics.COM Readtables
Received: from [192.10.41.223] by SU-AI.ARPA with TCP; 30 Apr 86 10:22:53 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 13326; Wed 30-Apr-86 13:20:37 EDT
Date: Wed, 30 Apr 86 13:19 EDT
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: Readtables
To: Brad Miller <lab@ROCHESTER.ARPA>
cc: DCP@SCRC-QUABBIN.ARPA, GJC@MC.LCS.MIT.EDU, common-lisp@SU-AI.ARPA
In-Reply-To: <8604301601.29900@ur-seneca.rochester.arpa>
Message-ID: <860430131930.8.DCP@FIREBIRD.SCRC.Symbolics.COM>
I don't have any good answers for you right now, but I do have some
comments. Your message does illustrate the issue quite well, thanks.
It could be argued that a different readtable is really implementing a
parser for a different language. Indeed, the Symbolics implementatin
supports two languages on the same machine: Zetalisp and Symbolics
Common Lisp. They do have different readtables and they also have
different package hierarchies. There is a command (Set Lisp Syntax, I
think) I think that selects between the two and sets up all the
necessary environment variables, which include package and readtable.
The editor also knows about this. This point of view says there should
be a concept of a 'language' which is the right collection of 'things'.
This thing of yours, however:
(pkg-goto 'USER)
<invoking !foo would mean !foo - no macro invocation,
invoking A:!foo WOULD invoke the macro>
(pkg-goto 'A)
<invoking !foo would invoke the macro
invoking B:!foo would NOT>
would definitely be part of the language. I'm not sure I like it
though because it is very surprising behavior (based on today's
paradigms).
As for your doing development on two or more programs, I think if the
compiler and loader bound *readtable* around the compile/load operation,
then you wouldn't have any problem because CLtL's development paradigm
is file-at-a-time operations. This leaves two major areas, I think:
incremental development (which is programming environment) and using the
two programs (which isn't, or is at least fuzzy).
Incremental development usually means incremental editing and compiling
out of the editor buffer. Here it would be nice if the editor knew what
the necessary variables in order to understand the language are. This
could be an extension to the -*- line to the systems that do such
things.
Using the programs, or typing to "its reader" is the unclear issue for
me. Currently, FOO: affects the translation from strings to symbols,
and you want it to affect the parsing of text at a more global level. I
think that might be a useful thing, but I don't think : is the place to
put it, but instead something else (@?). There is the question: Should
this affect the next form in that parser's language or should it affect
all forms until an escape in the other language switches back or out?
∂30-Apr-86 1127 lab@rochester.arpa Readtables
Received: from ROCHESTER.ARPA by SU-AI.ARPA with TCP; 30 Apr 86 11:27:06 PDT
Received: from ur-seneca.rochester.arpa (ur-seneca) by ur-cayuga.rochester.arpa id AA00377 (4.12w); Wed, 30 Apr 86 14:27:28 edt
Received: by ur-seneca.rochester.arpa id AA02438 (4.12w); Wed, 30 Apr 86 14:04:57 edt
Message-Id: <8604301804.2438@ur-seneca.rochester.arpa>
Date: Wed, 30 Apr 86 14:04:57 edt
From: Brad Miller(Tech. Ops. Mgr) <lab@rochester.arpa>
To: DCP@SCRC-QUABBIN.ARPA
Cc: lab@rochester.arpa, DCP@SCRC-QUABBIN.ARPA, GJC@MC.LCS.MIT.EDU,
common-lisp@SU-AI.ARPA
In-Reply-To: David C. Plummer's message of Wed, 30 Apr 86 13:19 EDT
Subject: Readtables
Well, more answers, as usual, bring more questions....
A purely environmental work-around might be to set the readtable in
different listeners differently. This doesn't help you 'break out' of
the readtable into another program's readtable, however. I suspect the
least confusing thing would be to have some syntax to break out on a
local (single string) level rather than until an escape, e.g.
(similar to before the ! macro)
(pkg-goto 'USER) ;no macros
(!foo A:!foo !foo) ;1st and 3rd do not use macro, A:!foo does if A:
has defined it.
Now, we may want to say:
(!foo A:@*foo-readtable*!foo !foo)
but my feeling is that this sort of explict declaration of readtables
is rather clumsy at best, at least for 'normal' usage. Having such a
mechanism exist is probably a good idea though.
Part of the problem with distinguishing readtables and languages from
packages is that languages are ALSO designed with their own packages.
(Since they must inherit the meanings of their constructs from some
'definitional' package - e.g. CL for common-lisp on Symbolics.) It
seems like it would be less confusing to a USER if they were
associated a little closer. Now, you are quite correct in what you are
about to say: that if I try to invoke some function in CL from
Zetalisp, I should not have to say CL:frozzbozz where frozzbozz is in
the CL dialect - I should just have to name the function in that
package, which is where your distinction has appeal.
Let me give another example which illuminates the problem more
succinctly:
Say I write a program using the macro #\!. Since I don't want a
separate 'listener' or any other such reader for this program, I
define it in the default readtable. It gets saved in the world. Naive
user #1 comes up to use the machine and decides his variables should
all start with !. Silly Luser! He gets his variables clobbered by the
macro defined in my package, even though my package is NOT part of
USER, :USEd by USER, or anything else. Yet hack user #2 comes up t the
machine and happily calls functions in my FOO: package, knowing his
!'s will all be interpreted appropriately, even though his default
package is USER.
The thing that will be the most obvious to both users is to have the
macro invocation local to the package. Luser 1 doesn't lose, and
doesn't even have to know about the existance of !. Hacker 2 still
wins big because whenever he invokes the FOO: package, he gets it's
readtable. Luser 1 is still served if we have a separate syntax for
defining readtables - ignorance is bliss. Hacker 2 is served, but
irritated perhaps, because he feels he is forced to supply redundant
information (you and I realize it isn't but still). Maybe the 'real'
solution is to support package names, readtable names, and a way to
set both with a single (new) name?
Just more incremental thoughts. Think the idea of putting extension on
-*- line for readtable solves THAT problem quite nicely. Hope
symbolics reads this mailing list and picks up on that!
B
∂30-Apr-86 1154 LOOSEMORE@UTAH-20.ARPA editing a function definition
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 30 Apr 86 11:51:14 PDT
Date: Wed 30 Apr 86 12:50:32-MDT
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: editing a function definition
To: common-lisp@SU-AI.ARPA
Message-ID: <12203009007.11.LOOSEMORE@UTAH-20.ARPA>
The manual says that doing (ed <symbol>) lets you edit the text for the
function named <symbol>, but it doesn't say what happens to it once you've
left the editor. Is the definition replaced by whatever you did in the
editor? If so, are other forms you added while in the editor evaluated
too?
Also, the manual leaves open the possibility of searching the file system
for the file containing the original definition of the function. Does this
mean that the entire file may be passed to the editor, or should the
definition of that one function be extracted from the file instead?
-Sandra
-------
∂30-Apr-86 1159 DCP@SAPSUCKER.SCRC.Symbolics.COM Readtables
Received: from [192.10.41.223] by SU-AI.ARPA with TCP; 30 Apr 86 11:54:34 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 13400; Wed 30-Apr-86 14:52:18 EDT
Date: Wed, 30 Apr 86 14:51 EDT
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: Readtables
To: Brad Miller <lab@ROCHESTER.ARPA>, DCP@SCRC-QUABBIN.ARPA
cc: GJC@MC.LCS.MIT.EDU, common-lisp@SU-AI.ARPA
In-Reply-To: <8604301804.2438@ur-seneca.rochester.arpa>
Message-ID: <860430145111.9.DCP@FIREBIRD.SCRC.Symbolics.COM>
Just one quickie. After this, you and I have probably said as much as
we can say to each other, and more input is needed from the rest of the
community.
I wasn't suggesting
A:@*foo-readtable*!foo
I was suggesting
A@!foo
where the A@ put the reader into program A's context, which includes
package, readtable and whatever else.
∂30-Apr-86 1342 DD60@A.CS.CMU.EDU readtables & packages
Received: from A.CS.CMU.EDU by SU-AI.ARPA with TCP; 30 Apr 86 13:40:11 PDT
Date: Wed, 30 Apr 86 15:25 EDT
From: David.Dill@A.CS.CMU.EDU (C410DD60)
To: common-lisp@SU-AI.ARPA
Subject: readtables & packages
Message-Id: <30Apr86.152509.DD60@A.CS.CMU.EDU>
As far as I'm concerned, associating readtables with packages is a bad
heuristic for always having the right readtable in effect. Also,
in my experience, the problem for which this solution is proposed does
not arise very often, nor is it particularly troublesome. The package
system was designed for structuring large systems -- the fact that it
is handy for embedding other dialects of lisp or entirely different
programming languages is gravy. People who take it upon themselves
to have a variety of readtables in simultaneous use can also make the
extra effort to add facilities for switching between them conveniently.
Are you folks even talking about the common lisp package system? All this
discussion about hierarchies makes it sound more like the lisp machine
package system.
∂30-Apr-86 1444 RAM@C.CS.CMU.EDU FUNCTION and MACROLET
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 30 Apr 86 14:43:55 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Wed 30 Apr 86 17:44:20-EDT
Date: Wed, 30 Apr 1986 17:44 EDT
Message-ID: <RAM.12203040636.BABYL@>
From: Rob MacLachlan <RAM@λλ>
To: NGALL@BBNG.ARPA
Cc: Common-Lisp@SU-AI.ARPA, nttlab!kurims!yuasa@SU-SHASTA.ARPA
Subject: FUNCTION and MACROLET
In-reply-to: Msg of 30 Apr 1986 10:28-EDT from NGALL at G.BBN.COM
To me, it isn't an obvious clarification that FUNCTION can return
strange objects. I always though of function as causing "functional
evaluation", and would always result in a callable object.
Are people really suggesting that the compiler should arrange to
compile and dump macrolet functions? Is this legal?
(defun def-a-macro (name)
(macrolet ((foo (a b) `(cons ,a ,b)))
(setf (symbol-function name) #'foo)))
Of course, if the manual is interpreted as saying that *nothing*
is guaranteed about what symbol-function returns in the non-function
case, then the compiler could compile the FUNCTION call so that it
returned something totally random.
Unless more is guaranteed about what SYMBOL-FUNCTION does in the
non-function case, this option is useless. I think it would better to
say that it is an error to call SYMBOL-FUNCTION on any symbol which
isn't the name of a function. Sensibly, it is illegal to do anything
with a special-form object, and it is much more tasteful to manipulate macro
definitions using MACRO-FUNCTION, so it seems that the ability to call
SYMBOL-FUNCTION on non-functions it worthless. And it we change
SYMBOL-FUNCTION in this way, then it would be consistent with what
FUNCTION already does in Spice Lisp.
Rob
∂30-Apr-86 1553 NGALL@G.BBN.COM Re: FUNCTION and MACROLET
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 30 Apr 86 15:52:37 PDT
Date: 30 Apr 1986 18:55-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: FUNCTION and MACROLET
From: NGALL@G.BBN.COM
To: Common-Lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]30-Apr-86 18:55:25.NGALL>
In-Reply-To: <RAM.12203040636.BABYL@>
Date: Wed, 30 Apr 1986 17:44 EDT
From: Rob MacLachlan <RAM@λλ>
To: NGALL@BBNG.ARPA
Subject: FUNCTION and MACROLET
In-Reply-To: Msg of 30 Apr 1986 10:28-EDT from NGALL at G.BBN.COM
Message-ID: <RAM.12203040636.BABYL@>
To me, it isn't an obvious clarification that FUNCTION can return
strange objects. I always though of function as causing "functional
evaluation", and would always result in a callable object.
Are people really suggesting that the compiler should arrange to
compile and dump macrolet functions? Is this legal?
(defun def-a-macro (name)
(macrolet ((foo (a b) `(cons ,a ,b)))
(setf (symbol-function name) #'foo)))
Of course, if the manual is interpreted as saying that *nothing*
is guaranteed about what symbol-function returns in the non-function
case, then the compiler could compile the FUNCTION call so that it
returned something totally random.
Unless more is guaranteed about what SYMBOL-FUNCTION does in the
non-function case, this option is useless. I think it would better to
say that it is an error to call SYMBOL-FUNCTION on any symbol which
isn't the name of a function. Sensibly, it is illegal to do anything
with a special-form object, and it is much more tasteful to manipulate macro
definitions using MACRO-FUNCTION, so it seems that the ability to call
SYMBOL-FUNCTION on non-functions it worthless. And it we change
SYMBOL-FUNCTION in this way, then it would be consistent with what
FUNCTION already does in Spice Lisp.
Rob
--------------------
I agree that SYMBOL-FUNCTION should be redefined so that "it is an
error" to give it a symbol that is fbound as a macro or special-form
and that FUNCTION be defined analogously. That will require an
incompatible change to the language, whereas Guy's clarification
(which I was merely interpreting, not supporting) does not. I am in
favor of such a change, but then I don't have to implement it.
-- Nick
∂30-Apr-86 2006 FAHLMAN@C.CS.CMU.EDU editing a function definition
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 30 Apr 86 20:06:49 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 30 Apr 86 23:07:40-EDT
Date: Wed, 30 Apr 1986 23:07 EDT
Message-ID: <FAHLMAN.12203099501.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: editing a function definition
In-reply-to: Msg of 30 Apr 1986 14:50-EDT from SANDRA <LOOSEMORE at UTAH-20.ARPA>
The manual says that doing (ed <symbol>) lets you edit the text for the
function named <symbol>, but it doesn't say what happens to it once you've
left the editor. Is the definition replaced by whatever you did in the
editor? If so, are other forms you added while in the editor evaluated
too?
Also, the manual leaves open the possibility of searching the file system
for the file containing the original definition of the function. Does this
mean that the entire file may be passed to the editor, or should the
definition of that one function be extracted from the file instead?
All of this is totally up to the implementor of the Lisp environment.
In fact, implementing ED is optional. The only purpose of including
this function is to provide a standard way of getting over to the editor
to edit the source for a given function, IF that sort of operation makes
sense in your implementation.
My own opinion (none of which is or should be in the Common Lisp spec)
is that an Emacs-like editor ought to zap you over to the right place in
the right file. I don't much care if it sets up buffer bounds around
the function, but it should be easy to get loose and edit other stuff in
the file. Facilities must be provided for moving the just-edited
function and any number of other forms back into the Lisp. I have no
opinions about what an Interlisp-like in-core editor should do.
-- Scott
∂01-May-86 0108 @MIT-REAGAN.ARPA:cfry@OZ.AI.MIT.EDU Environment Query Functions.
Received: from MIT-REAGAN.ARPA by SU-AI.ARPA with TCP; 1 May 86 01:07:59 PDT
Received: from DUANE.AI.MIT.EDU by MIT-REAGAN.ARPA via CHAOS with CHAOS-MAIL id 30625; Thu 1-May-86 04:09:49-EDT
Date: Thu, 1 May 86 04:09 EDT
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
Subject: Environment Query Functions.
To: greek%bach.decnet@hudson.dec.com, common-lisp@SU-AI.ARPA
In-Reply-To: The message of 28 Apr 86 11:36-EDT from "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Message-ID: <860501040913.2.CFRY@DUANE.AI.MIT.EDU>
I think the watchword is "short and sweet" as far as the environment
query functions are concerned. Here's what we do for VAX LISP.
LISP-IMPLEMENTATION-TYPE is "VAX LISP".
LISP-IMPLEMENTATION-VERSION is something like "V2.0".
MACHINE-TYPE is the machine name, like "DEC VAX 11/780" "DEC VAXstation II".
MACHINE-VERSION is tough to call, so we return the SID register, which
uniquely identifies the CPU. Not so great.
MACHINE-INSTANCE is setable by the system manager/user.
SOFTWARE-TYPE is "VMS" or "ULTRIX".
SOFTWARE-VERSION is whatever the operating system says its version is.
SHORT-SITE-NAME & LONG-SITE-NAME is setable by the system manager/user.
There's a few reasons for these variables:
-to help a user figure out what environment he's in
-to help a program ...
Generally programs care that certain values that ought to be the
same are identical, and certain things that ought to be unique
really are.
An example of "the same" is, if 2 different lisps both run on
a VAX 780, then they ought to have identical values for MACHINE-TYPE.
An example of difficulty with cases for uniqueness might come
in the SHORT-SITE-NAME for a
site in Paris, France and Paris, Texas.
[They BOTH might decide to use "ROME Air Force" ! ]
The world is big, and there's lots of hardware/ operating systems
out there, but with a little coordination we could:
Provide reasonable values for these vars that were unique when they need to be
and the same when they need to be.
I propose that a clearinghouse for such names occur at ISI as part of
the validation suite effort.
We need to come up for rules of reasonability for names,
and a mechanism for distributing the Known Nameset
[say every 3 months?] so that people writting portable code
can have at least some chance of doing it right.
Maybe in the process of doing this we'll discover that certain
of the above vars are useless, and/or that a few more should be added.
All the more reason for centralizing the process.
∂01-May-86 0540 RAM@C.CS.CMU.EDU FUNCTION and MACROLET
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 1 May 86 05:37:08 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Thu 1 May 86 08:37:50-EDT
Date: Thu, 1 May 1986 08:37 EDT
Message-ID: <RAM.12203203291.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: NGALL@BBNG.ARPA
Cc: Common-Lisp@SU-AI.ARPA
Subject: FUNCTION and MACROLET
In-reply-to: Msg of 30 Apr 1986 18:55-EDT from NGALL at G.BBN.COM
I'm not sure I agree that it would be an incompatible change to
say that calling SYMBOL-FUNCTION with a non-function symbol is an
error. The current manual guarantees nothing about what is currently
returned, so no portable program can use SYMBOL-FUNCTION on
non-function symbols. Saying that it "is an error" to use
SYMBOL-FUNCTION on non-functions wouldn't require anyone to change
anything, since implementations can choose to define SYMBOL-FUNCTION
to do whatever it currently does in the non-function case.
The only discernible use for SYMBOL-FUNCTION on non-function
symbols is setting the SYMBOL-FUNCTION of one symbol to be the same as
that of another:
(setf (symbol-function 'new-macro) (symbol-function 'old-macro))
Note that nowhere in the manual does it say that this will work.
There is no need to define it to work, since MACRO-FUNCTION can do the
same job better.
Rob
∂01-May-86 0653 greek%bartok.decnet@hudson.dec.com Environment Query Functions.
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 1 May 86 06:53:36 PDT
Date: 1 May 86 09:40:00 EST
From: "BARTOK::GREEK" <greek%bartok.decnet@hudson.dec.com>
Subject: Environment Query Functions.
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BARTOK::GREEK" <greek%bartok.decnet@hudson.dec.com>
I think the environment query functions like MACHINE-TYPE ought to be
limited to human-readable information. If programs need to make
decisions based on this information they should use te *FEATURES* list.
All that aside, I certainly agree that a lot of this information needs
to be registered. I volunteered to be the registrar about six months
ago, but that led nowhere. Who really wants to be restricted in what
they can do?
- Paul
------
∂01-May-86 0746 DLW@SAPSUCKER.SCRC.Symbolics.COM editing a function definition
Received: from [192.10.41.223] by SU-AI.ARPA with TCP; 1 May 86 07:46:43 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 13826; Thu 1-May-86 10:44:40 EDT
Date: Thu, 1 May 86 10:48 EDT
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: editing a function definition
To: Fahlman@C.CS.CMU.EDU, LOOSEMORE@UTAH-20.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12203099501.BABYL@C.CS.CMU.EDU>
Message-ID: <860501104847.8.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Wed, 30 Apr 1986 23:07 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
My own opinion (none of which is or should be in the Common Lisp spec)
is that an Emacs-like editor ought to zap you over to the right place in
the right file.
Indeed, this is what the traditional Lisp machine ED function does, and
it's similar to several facilities provided in time-sharing system
Lisps, such as LEDIT from MIT.
I think the paragraph as the beginning of the "Debugging Tools" chapter
needs some more-explicit text, explaining that the behavior of these
functions, unlike those in the rest of the manual, is NOT intended to be
fully specified by the Common Lisp definition; that they are only
conventions to try to help users get started in different CL programming
environments by providing some common names; and that portable programs
cannot depend on their behavior. You can infer this from the existing
text, but I think a more explicit warning is warranted, since this is
such a departure from the philosopy of the rest of the definition of the
language.
∂01-May-86 1716 RAM@C.CS.CMU.EDU Does defmacro need a lexicality barrier?
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 1 May 86 17:11:11 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Thu 1 May 86 20:11:54-EDT
Date: Thu, 1 May 1986 20:11 EDT
Message-ID: <RAM.12203329635.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: Pavel.pa@XEROX.COM
Cc: Common-Lisp@SU-AI.ARPA
Subject: Does defmacro need a lexicality barrier?
In-reply-to: Msg of 1 May 1986 19:24-EDT from Pavel.pa at Xerox.COM
The definition of DEFMACRO clearly says that the body of the macro
is in the null environment. Although "it is an error" to refer to an
unbound variable, you do have to make the environment null because
information related to a lexical binding around the defmacro would
erroneously be attached any free variable with the same name in the
body.
In Spice Lisp, we have an internal special form
IN-GLOBAL-ENVIRONMENT which is used for this exact purpose.
Rob
∂01-May-86 1624 Pavel.pa@Xerox.COM Does defmacro need a lexicality barrier?
Received: from XEROX.COM by SU-AI.ARPA with TCP; 1 May 86 16:24:26 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 01 MAY 86 16:24:08 PDT
Date: 1 May 86 16:24 PDT
From: Pavel.pa@Xerox.COM
Subject: Does defmacro need a lexicality barrier?
To: Common-Lisp@SU-AI.ARPA
Message-ID: <860501-162408-1662@Xerox>
It is not clear to me how defmacro is supposed to create the expansion
function to be stored as the macro-function of the given symbol. The
issues related to understanding the argument list are reasonably
obvious, but those relating to the lexical scope of the function are
not.
Consider the following oversimplified outline for the definition of
defmacro:
(defmacro defmacro (name arg-list &body body)
... analyze the argument list and construct the pieces out of
which
... an expansion funcion could be put together. Store the
actual
... S-expression on the variable expansion-function.
`(setf (macro-function ,name) ,expansion-function) )
This definition ignores such features as documentation strings, but what
I'm really concerned about is what to put in the variable
``expansion-function''. If we set it to something like
#'(lambda (form env) ...)
then the macro body will have access to any variables in the lexical
environment of the defmacro. It appears that we could fix that by
changing #' into simply ':
'(lambda (form env) ...)
Unfortunately, this implies reasonably strongly that the macro body will
not be compiled, since it is only a random list. I suppose that it is
possible that the compiler would notice that this random list is being
stuck somewhere that a funcallable object is supposed to go, but it
doesn't sound either likely or correct. If I am worried about getting
the expansion function compiled, but in the correct (null) lexical
environment, I guess I can set ``expansion-function'' to
(compile nil '(lambda (form env) ...))
This has the somewhat strange effect of preventing the existence of
interpreted macros. Surely this is not the intent of the design of
Common Lisp.
What I would really like is a method for the construction of
``closures'' over the null lexical environment. As far as I can tell,
Common Lisp does not supply such a mechanism. Am I just totally
confused? Is this whole point moot? After all, what is the meaning of
a defmacro that makes reference to lexical variables? If it ``is an
error'', then I can use the #' solution above.
What does everyone else do? Do we need a new special form
``with-null-lexical-environment''?
Pavel
∂01-May-86 1831 Miller.pa@Xerox.COM Re: Does defmacro need a lexicality barrier?
Received: from XEROX.COM by SU-AI.ARPA with TCP; 1 May 86 18:31:26 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 01 MAY 86 18:27:22 PDT
Date: 1 May 86 18:27 PDT
From: Miller.pa@Xerox.COM
Subject: Re: Does defmacro need a lexicality barrier?
In-reply-to: Pavel.pa's message of 1 May 86 16:24 PDT
To: Pavel.pa@Xerox.COM
cc: Common-Lisp@SU-AI.ARPA
Message-ID: <860501-182722-1807@Xerox>
Date: 1 May 86 16:24 PDT
From: Pavel.pa
Subject: Does defmacro need a lexicality barrier?
[...]
What I would really like is a method for the construction of
``closures'' over the null lexical environment. As far as I can tell,
Common Lisp does not supply such a mechanism
What about
(EVAL '#'(lambda (x y) ...) NIL)
-- MarkM
∂01-May-86 2145 KMP@SCRC-STONY-BROOK.ARPA Problems with packages
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 1 May 86 21:33:57 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 478192; Thu 1-May-86 22:53:42-EDT
Date: Thu, 1 May 86 22:53 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Problems with packages
To: Common-Lisp@SU-AI.ARPA
Message-ID: <860501225353.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I ran into a problem the other day in Symbolics (extended) Common Lisp
where I was doing a DEFPACKAGE which specified some shadowed symbols and
lossage resulted due to a bug where the package creation wasn't done atomically.
For those not familiar with DEFPACKAGE, we can write:
(DEFPACKAGE "FOO"
(:USE "FRED")
(:SIZE 10000.)
(:IMPORT HACKS:FOO COLOR:PAINT MATH:SOLVE ...)
(:SHADOW "JOE" "MARY" "SALLY")
(:EXPORT "JOE" "PAINT"))
The problem was that I was trying to read into the editor in one process
a file on the `FOO' package while I was loading the system in another
process which defined the `FOO' package. For those not familiar with the Lisp
Machine architecture, both processes share the same global environment
(including, therefore, package declarations). I was expecting that it was
going to say that `FOO' wasn't defined and I was going to tell it to use
`USER' for my editing purposes now while the system loaded. Something
much worse happened...
What happened was that I hit a bad timing window and it tried to resolve
the `FOO' package at the instant the package was created but before the
special stuff (like shadowing, importing, etc.) had been done. The editor
managed to add some symbols to the `FOO' package before the process in the
other window managed to process the shadows, resulting in lossage when the
shadow information finally got processed and the system realized that the
symbols in question had already been interned without knowing about the
shadow information.
In our environment, we can treat this as a simple bug and just have DEFPACKAGE
run without interrupts or have it take an appropriate lock on the package
during its creation so that any other process trying to do an intern or
lookup blocks waiting for the operation to finish.
However, in normal Common Lisp, because of the absence of DEFPACKAGE,
there would be no way to do this because you can't really tell when you're
done creating a package. IN-PACKAGE can't leave the package locked because
it might be that no calls to SHADOW and friends follow. Even if they did
follow, you can't tell when they're done following. What a mess. CL
should have DEFPACKAGE.
While I'm on the subject of packages, I have a few other gripes to air...
I'm really bothered that I have to say symbols as arguments to shadow. The 3600
implementation allows me to use strings, which CL doesn't define. CL should
-require- strings as arguments to this function and should not allow symbols.
Giving symbols as arguments to this function forces things to get created wrong
and then hopes that things will get cleaned up correctly afterward. This reduces
the ability to error-check if the symbol to be shadowed had already been interned
for some reason other than the call to shadow. The same situation applies to
EXPORT, etc. -- except for IMPORT, for which it would seem perfectly reasonable
to require symbols (and forbid strings).
Finally, it bothers me that there isn't a version of IN-PACKAGE that doesn't
require the package to exist. Macsyma has about 200 source files and every one
of them starts with IN-PACKAGE. It also shadows about 20 symbols and I'm not
(for reasons of modularity) going to repeat the SHADOW declaration at the top
of every one of those files. I define the package early on and everything works
mostly ok, but if someone were to read the files out of order, the package would
get created incorrectly because no shadow information would get seen. Yet no
error would get signalled because IN-PACKAGE would still create the package. I
really want the file that declares the package to contain a call to IN-PACKAGE
and all the other files to call some function IN-EXISTING-PACKAGE which
errs if the package doesn't exist, but which otherwise does what IN-PACKAGE does.
∂02-May-86 0440 GJC@MC.LCS.MIT.EDU Problems with packages: work arounds.
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 2 May 86 04:40:26 PDT
Date: Fri, 2 May 86 07:42:12 EDT
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Subject: Problems with packages: work arounds.
To: KMP@SCRC-STONY-BROOK.ARPA
cc: Common-Lisp@SU-AI.ARPA
In-reply-to: Msg of Thu 1 May 86 22:53 EDT from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
Message-ID: <[MC.LCS.MIT.EDU].901826.860502.GJC>
If you still have the (MACSYMA-MODULE <name>) as the first form in
every file you can do what I do for DOE-MACSYMA,
(macsyma-module <name>) => (eval-when (eval compile load)
(or (find-package "MACSYMA") (error "bad news"))
... etc ...)
∂02-May-86 0528 somewhere!yuasa@kurims.kurims.kyoto-u.junet
Received: from SU-SHASTA.ARPA by SU-AI.ARPA with TCP; 2 May 86 05:28:12 PDT
Received: by su-shasta.arpa with TCP; Fri, 2 May 86 05:28:12 pdt
Received: by ntt.junet (4.12/4.7JC-7) CHAOS with CHAOS-MAIL
id AA12816; Fri, 2 May 86 16:56:07 jst
From: yuasa@kurims.kurims.kyoto-u.junet
Received: by ntt.junet (4.12/4.7JC-7) CHAOS with CHAOS-MAIL
id AA12634; Fri, 2 May 86 16:53:43 jst
Received: by kurims.kyoto-u.junet (2.0/4.7)
id AA01090; Fri, 2 May 86 17:43:51 pdt
Date: Fri, 2 May 86 17:43:51 pdt
Message-Id: <8605030043.AA01090@kurims.kyoto-u.junet>
To: Common-Lisp@SU-AI.ARPA
Subject: FUNCTION and MACROLET
To sum up, there are two possibilities:
[A] (MACROLET ((FOO ...)) (FUNCTION FOO)) causes an error, and
SYMBOL-FUNCTION with non-function symbol also causes an error.
[B] (MACROLET ((FOO ...)) (FUNCTION FOO)) returns some totally random object
which, when invoked as a function, will cause an error. SYMBOL-FUNCTION
with non-function symbol also returns something not a function.
CLtL supports [B]. Also Guy's proposed clarification seems to support [B].
However, [B] forces the compiler to INVENT something not a function, and to
silently generate code that returns the something, although this something is
totally useless. Rather, the compiler should cause an error when processing
the above MACROLET form. I prefer [A]. As Rob said, the difference of [A]
and [B] do not matter actually. In addition, it will be straightforward
to change an already existing implementation toward [A]. (Indeed, I think
I could do the change in five minutes for KYOTO!!)
The above discussions (and the discussions of Bob and Nick) are based on
Nick's assumption that FUNCTION with a symbol should correspond to
SYMBOL-FUNCTION in sense that a symbol as a variable corresponds
to SYMBOL-VALUE). Is this what most people agree with? Yes, the description
of FUNCTION in CLtL says
...; see SYMBOL-FUNCTION.
The reader of CLtL might see the description of SYMBOL-FUNCTION. Perhaps
he would like to say "yes, I saw it... so what?"
-- Taiichi
∂02-May-86 0716 RAM@C.CS.CMU.EDU Problems with packages
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 2 May 86 07:16:06 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Fri 2 May 86 10:16:55-EDT
Date: Fri, 2 May 1986 10:16 EDT
Message-ID: <RAM.12203483459.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Subject: Problems with packages
In-reply-to: Msg of 1 May 1986 22:53-EDT from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
Date: Thursday, 1 May 1986 22:53-EDT
From: Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
To: Common-Lisp at SU-AI.ARPA
Re: Problems with packages
...
What happened was that I hit a bad timing window and it tried to resolve
the `FOO' package at the instant the package was created but before the
special stuff (like shadowing, importing, etc.) had been done. ...
Sounds like an environment issue to me :-)
While I'm on the subject of packages, I have a few other gripes to
air...
I'm really bothered that I have to say symbols as arguments to
shadow. The 3600 implementation allows me to use strings, which CL
doesn't define. CL should -require- strings as arguments to this
function and should not allow symbols. Giving symbols as
arguments to this function forces things to get created wrong and
then hopes that things will get cleaned up correctly afterward.
This reduces the ability to error-check if the symbol to be
shadowed had already been interned for some reason other than the
call to shadow.
I don't quite follow what you are saying about "things getting created
wrong." If the call to shadow is read in the package which them
symbols are to be shadowed in, then:
1] The symbols get created as internal symbols in the package, in
which case shadow does nothing but update the shadowing symbols
list.
2] The symbols were already directly present in the package, in which
case both reading and shadowing do nothing but update the
shadowing symbols list.
3] The symbols are inherited from somewhere, in which case the
"wrong" symbol is read, but nothing is "created wrong", since the
symbol already existed.
It is a bit odd that SHADOW takes a list of symbols and then just uses
the names, but it doesn't have any bad side-effects that I can see. I
would guess that consistency was the motivation for using symbols
everywhere. Using symbols also lets those of us who dislike uppercase
type the names of the arguments in lowercase.
Rob
∂02-May-86 0756 FAHLMAN@C.CS.CMU.EDU
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 2 May 86 07:54:17 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 2 May 86 10:55:02-EDT
Date: Fri, 2 May 1986 10:54 EDT
Message-ID: <FAHLMAN.12203490405.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Common-Lisp@SU-AI.ARPA
In reply to: yuasa at kurims.kurims.kyoto-u.junet
To sum up, there are two possibilities:
[A] (MACROLET ((FOO ...)) (FUNCTION FOO)) causes an error, and
SYMBOL-FUNCTION with non-function symbol also causes an error.
[B] (MACROLET ((FOO ...)) (FUNCTION FOO)) returns some totally random object
which, when invoked as a function, will cause an error. SYMBOL-FUNCTION
with non-function symbol also returns something not a function.
I think that the right move is to go with interpretation A, except that
we would say "is an error" instead of "cuases an error". If existing
implementations do something like B, they would still be allowed, but
people could not count on this behavior in portable code, and it would
be more tasteful to signal an error.
In general, I think we need to allow implementors maximum leeway in
dealing with the function cell and related structures -- the performance
implications can be very substantial. We don't really need to use the
function cell as a place to store random things, and the ability to do
(setf (symbol-function 'foo) (symbol-function 'bar)) for non-functions
is not worth much.
-- Scott
∂02-May-86 0808 NGALL@G.BBN.COM FUNCTION and MACROLET
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 2 May 86 08:07:29 PDT
Date: 2 May 1986 11:10-EDT
Sender: NGALL@G.BBN.COM
Subject: FUNCTION and MACROLET
From: NGALL@G.BBN.COM
To: Common-Lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM] 2-May-86 11:10:15.NGALL>
In-Reply-To: <8605030043.AA01090@kurims.kyoto-u.junet>
Date: Fri, 2 May 86 17:43:51 pdt
From: yuasa@kurims.kurims.kyoto-u.junet
To: Common-Lisp@SU-AI.ARPA
Message-ID: <8605030043.AA01090@kurims.kyoto-u.junet>
Subject: FUNCTION and MACROLET
To sum up, there are two possibilities:
[A] (MACROLET ((FOO ...)) (FUNCTION FOO)) causes an error, and
SYMBOL-FUNCTION with non-function symbol also causes an error.
[B] (MACROLET ((FOO ...)) (FUNCTION FOO)) returns some totally random object
which, when invoked as a function, will cause an error. SYMBOL-FUNCTION
with non-function symbol also returns something not a function.
CLtL supports [B]. Also Guy's proposed clarification seems to support [B].
However, [B] forces the compiler to INVENT something not a function, and to
silently generate code that returns the something, although this something is
totally useless. Rather, the compiler should cause an error when processing
the above MACROLET form. I prefer [A]. As Rob said, the difference of [A]
and [B] do not matter actually. In addition, it will be straightforward
to change an already existing implementation toward [A]. (Indeed, I think
I could do the change in five minutes for KYOTO!!)
The above discussions (and the discussions of Bob and Nick) are based on
Nick's assumption that FUNCTION with a symbol should correspond to
SYMBOL-FUNCTION in sense that a symbol as a variable corresponds
to SYMBOL-VALUE). Is this what most people agree with? Yes, the description
of FUNCTION in CLtL says
...; see SYMBOL-FUNCTION.
The reader of CLtL might see the description of SYMBOL-FUNCTION. Perhaps
he would like to say "yes, I saw it... so what?"
Nick's assumption is wrong here. On pg. 32 it says "The result of
evaluating a FUNCTION special form will always be a function."
Thus, even in the current CLtL, FUNCTION and SYMBOL-FUNCTION are
not defined to behave identically in the the case of a symbol that
globally names a macro or special form.
Given that FUNCTION is not defined to work with symbols naming
non-functions and given that MACRO-FUNCTION can be used to assign a
new name to a macro, and given that we probably want it to be illegal
to give a new name to a special form (I think we discussed this aspect
of SYMBOL-FUNCTION once), then I agree that [A] is the best solution
(assuming that "causes an error" does not mean "signal an error" but
merely "is an error").
-- Nick
∂02-May-86 1237 KMP@SCRC-STONY-BROOK.ARPA Problems with packages
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 2 May 86 12:36:46 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 478730; Fri 2-May-86 14:10:47-EDT
Date: Fri, 2 May 86 14:10 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Problems with packages
To: GJC@MC.LCS.MIT.EDU, RAM@C.CS.CMU.EDU
cc: Common-Lisp@SU-AI.ARPA, KMP@SCRC-STONY-BROOK.ARPA
In-Reply-To: <[MC.LCS.MIT.EDU].901826.860502.GJC>,
Your message
References: <860501225353.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <860502141057.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Fri, 2 May 86 07:42:12 EDT
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Subject: Problems with packages: work arounds.
If you still have the (MACSYMA-MODULE <name>) as the first form in
every file you can do what I do for DOE-MACSYMA,
(macsyma-module <name>) => (eval-when (eval compile load)
(or (find-package "MACSYMA") (error "bad news"))
... etc ...)
The issue is not finding a work-around. Obviously I know how to achieve the
computational effect. The issue is that:
(a) no one should put their shadowed symbols list in more than one file
because it just sets them up to lose by getting the various lists
out of alignment with each other.
(b) everyone who uses files that do IN-PACKAGE for a complicated package
like the one I'm describing should probably want to do the same workaround.
One purpose of language design is to make sure that idioms get names.
Another is to make it convenient to get the appropriate error checking for those
who may be too lazy to write the error conditional long-hand. Why should everyone
have to invent a MACSYMA-MODULE routine? Introducing an IN-EXISTING-PACKAGE
primitive would be good for everyone.
By the way, another potential problem with the MACSYMA-MODULE scheme you outline
is that you can't be sure on what package the MACSYMA-MODULE form will be read.
As such, unless you are sure MACSYMA-MODULE is defined in all possible packages,
the call to IN-PACKAGE must preceed the call to MACSYMA-MODULE so that
MACSYMA-MODULE will get interned in the correct package, which defeats the
purpose. Yes, it's possible to make the MACSYMA-MODULE thing work, but I don't
think very portably and I don't think that when it fails it will fail gracefully.
Yes, it's possible to make IN-PACKAGE work, but again when it fails it is not
going to fail gracefully. I think the language should provide minimal support
for common situations like this where the system could and should be doing
error checking.
It's only -very- rarely going to be the case that the person writes IN-PACKAGE
and doesn't know whether he means IN-PACKAGE or IN-EXISTING-PACKAGE. That being
the case, we should allow the person to say which he means and get the benefit
that should come from such clarity of expression.
Date: Fri, 2 May 1986 10:16 EDT
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
Date: Thursday, 1 May 1986 22:53-EDT
From: Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
To: Common-Lisp at SU-AI.ARPA
Re: Problems with packages
...
What happened was that I hit a bad timing window and it tried to resolve
the `FOO' package at the instant the package was created but before the
special stuff (like shadowing, importing, etc.) had been done. ...
Sounds like an environment issue to me :-)
Linguistic issues which make it impossible to construct correct environments are
within our charter. I claim this is such an issue.
While I'm on the subject of packages, I have a few other gripes to
air...
I'm really bothered that I have to say symbols as arguments to
shadow. The 3600 implementation allows me to use strings, which CL
doesn't define. CL should -require- strings as arguments to this
function and should not allow symbols. Giving symbols as
arguments to this function forces things to get created wrong and
then hopes that things will get cleaned up correctly afterward.
This reduces the ability to error-check if the symbol to be
shadowed had already been interned for some reason other than the
call to shadow.
I don't quite follow what you are saying about "things getting created
wrong." If the call to shadow is read in the package which them
symbols are to be shadowed in, then:
1] The symbols get created as internal symbols in the package, in
which case shadow does nothing but update the shadowing symbols
list.
2] The symbols were already directly present in the package, in which
case both reading and shadowing do nothing but update the
shadowing symbols list.
3] The symbols are inherited from somewhere, in which case the
"wrong" symbol is read, but nothing is "created wrong", since the
symbol already existed.
It is a bit odd that SHADOW takes a list of symbols and then just uses
the names, but it doesn't have any bad side-effects that I can see. I
would guess that consistency was the motivation for using symbols
everywhere. Using symbols also lets those of us who dislike uppercase
type the names of the arguments in lowercase.
I may have been a bit vague in my original exposition, so let me give a sample
of a problemsome situation. Suppose you put the following in a file:
(IN-PACKAGE 'FOO)
(SHADOW '(CAR))
Then suppose you type Suspend (or Control-B or whatever your asynchronous
interrupt is for getting a Lisp breakpoint ...) while the file is loading and
you (unknowingly) end up between the IN-PACKAGE and the SHADOW. You can verify
that the FOO package exists, but might not think to verify that BAR has not
yet been shadowed. Suppose you type (DEFUN FOO:CAR () 3) while in the breakpoint.
The problem is that FOO:CAR will resolve to LISP:CAR because the shadowing has
not yet been done. This is analagous to what happened to me in the
multiprocessing situation the other day. Also, when
(SHADOW '(CAR))
gets done, it will not know that you had previously interned FOO:CAR (in the
breakpoint) because it thinks the reason it finds FOO:CAR interned locally.
Also, if the implementation caches the results of doing
(INTERN inherited-symbol-name package) for faster lookup later and remembers
that FOO:CAR used to resolve to LISP:CAR, it can signal an error if it later
changes. If shadow takes a symbol argument, the implementation can't reliably
tell that you're doing something nasty because it can't tell if the only previous
use of FOO:CAR (which resolved to LISP:CAR) was the one in the call to shadow
or whether there were other, more substantial, uses of LISP:CAR which you might
want to be warned about.
Even leaving aside issues of asynchronous interrupts, there's no guaranteeing
that someone else hasn't done:
(IN-PACKAGE 'FOO)
and then just worked in FOO for a while before you loaded a package that
did
(IN-PACKAGE 'FOO)
(SHADOW '(CAR))
In that case, you can't appropriately flag any prior uses of CAR because
the form which calls SHADOW has basically destroyed any debugging information
that might have been around.
∂02-May-86 1603 Hornig@SCRC-STONY-BROOK.ARPA Environment Query Functions.
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 2 May 86 16:02:56 PDT
Received: from HOME.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 478959; Fri 2-May-86 17:41:19-EDT
Date: Fri, 2 May 86 17:41 EDT
From: Charles Hornig <Hornig@SCRC-RIVERSIDE.ARPA>
Subject: Environment Query Functions.
To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>,
common-lisp <common-lisp@SU-AI.ARPA>
In-Reply-To: The message of 28 Apr 86 11:36-EDT from "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Message-ID: <860502174133.3.HORNIG@HOME.SCRC.Symbolics.COM>
Date: 28 Apr 86 10:36:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
I think the watchword is "short and sweet" as far as the environment
query functions are concerned. Here's what we do for VAX LISP.
And here's what we do for Symbolics Common Lisp.
LISP-IMPLEMENTATION-TYPE is "VAX LISP".
"Symbolics Common Lisp"
LISP-IMPLEMENTATION-VERSION is something like "V2.0".
"System 271.266, TMC5-IO4-COL-MIC microcode 384"
MACHINE-TYPE is the machine name, like "DEC VAX 11/780" "DEC VAXstation II".
"Symbolics 3600"
MACHINE-VERSION is tough to call, so we return the SID register, which
uniquely identifies the CPU. Not so great.
A real long string which is a list of all of the components of the
system with their serial numbers.
MACHINE-INSTANCE is setable by the system manager/user.
The host name of the machine.
SOFTWARE-TYPE is "VMS" or "ULTRIX".
"Lisp Machine"
SOFTWARE-VERSION is whatever the operating system says its version is.
A long string which describes the loaded versions of all systems.
SHORT-SITE-NAME & LONG-SITE-NAME is setable by the system manager/user.
ditto
∂02-May-86 1630 edsel!sunvalleymall!eb@su-navajo.arpa Lexical references in DEFMACRO
Received: from SU-NAVAJO.ARPA by SU-AI.ARPA with TCP; 2 May 86 16:30:38 PDT
Received: by su-navajo.arpa with Sendmail; Fri, 2 May 86 16:30:40 pdt
Received: from sunvalleymall.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
id AA12915; Fri, 2 May 86 16:29:20 pdt
Return-Path: <eb@sunvalleymall>
Received: by sunvalleymall.edsel.uucp (2.2/SMI-2.2)
id AA07703; Fri, 2 May 86 16:27:58 pdt
Date: Fri, 2 May 86 16:27:58 pdt
From: edsel!sunvalleymall!eb@su-navajo.arpa (Eric Benson)
Message-Id: <8605022327.AA07703@sunvalleymall.edsel.uucp>
To: navajo!Common-Lisp@su-ai
Subject: Lexical references in DEFMACRO
The Common Lisp definition continues to surprise me. I had not
noticed that DEFMACRO is not allowed to let its body refer to any
lexically visible entities outside the DEFMACRO form. On the other
hand, DEFUN is specifically allowed to refer to lexically visible
entities. This deserves some explanation. It seems I am allowed to
do this:
(LET ((SOME-DATA-STRUCTURE (MAKE-SOME-DATA-STRUCTURE)))
(DEFUN SOME-FUNCTION ()
(DO-SOMETHING-WITH SOME-DATA-STRUCTURE)))
but not this:
(LET ((SOME-DATA-STRUCTURE (MAKE-SOME-DATA-STRUCTURE)))
(DEFMACRO SOME-MACRO ()
(MAKE-A-FORM-WITH SOME-DATA-STRUCTURE)))
To do what I want in the second case I must do this:
(LET ((SOME-DATA-STRUCTURE (MAKE-SOME-DATA-STRUCTURE)))
(SETF (MACRO-FUNCTION 'SOME-MACRO)
#'(LAMBDA (FORM ENVIRONMENT
(DECLARE (IGNORE FORM ENVIRONMENT))
(MAKE-A-FORM-WITH SOME-DATA-STRUCTURE)))))
Furthermore, in order to implement this restriction I must introduce a
new special form, such as that used in Spice Lisp, to force a form to
be evaluated in the null lexical environment. Thus it is impossible
to live up to the suggestion in the implementation note on p.58, that
macros should not expand into implementation-dependent special forms.
It is obvious to me why the expansion functions defined by MACROLET
must have this restriction; there is no environment at macroexpansion
time to which they can refer. The expansion functions created by
DEFMACRO, on the other hand, are not really very different from
ordinary functions created by DEFUN.
There is one difference, but it is outside the scope of the Common
Lisp definition. Most (i.e. all) implementations of Common Lisp cause
macros defined by DEFMACRO to be available for use while compiling the
file in which they are defined. This is not required by the Common
Lisp definition, but is part of the Lisp tradition. It should be
obvious that this is only possible for macro definitions which occur
at "top level." For example, it would be incorrect in this example to
define THIS-MACRO at compile time:
(WHEN SOME-CONDITION
(DEFMACRO THIS-MACRO ()
(EXPAND-INTO-SOMETHING)))
Similarly, any macro definition which refers to a lexically visible
entity cannot be defined at compile time, since it cannot be a "top
level" form.
I suggest one of the following be done in the next edition of the manual:
1. Remove the sentence in the description of DEFMACRO which disallows
references to lexically visible entities. This is an incompatible
change, but is unlikely to affect many programs. It is mostly an
upward-compatible change.
2. Add an explanation which justifies this restriction. The
explanation would have to include some language explaining how this
could be implemented, since it appears to contradict the
implementation note on p.58.
∂03-May-86 0710 RAM@C.CS.CMU.EDU Lexical references in DEFMACRO
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 3 May 86 07:10:22 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Sat 3 May 86 10:11:16-EDT
Date: Sat, 3 May 1986 10:11 EDT
Message-ID: <RAM.12203744585.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: edsel!sunvalleymall!eb@λsu-navajo.arpa (Eric Benson)λ
Cc: Common-Lisp@SU-AI.ARPA
Subject: Lexical references in DEFMACRO
In-reply-to: Msg of 2 May 1986 19:27-EDT from edsel!sunvalleymall!eb at su-navajo.arpa (Eric Benson)
Date: Friday, 2 May 1986 19:27-EDT
From: edsel!sunvalleymall!eb at su-navajo.arpa (Eric Benson)
Re: Lexical references in DEFMACRO
The Common Lisp definition continues to surprise me. I had not
noticed that DEFMACRO is not allowed to let its body refer to any
lexically visible entities outside the DEFMACRO form. On the other
hand, DEFUN is specifically allowed to refer to lexically visible
entities. This deserves some explanation. It seems I am allowed to
do this:
(LET ((SOME-DATA-STRUCTURE (MAKE-SOME-DATA-STRUCTURE)))
(DEFUN SOME-FUNCTION ()
(DO-SOMETHING-WITH SOME-DATA-STRUCTURE)))
but not this:
(LET ((SOME-DATA-STRUCTURE (MAKE-SOME-DATA-STRUCTURE)))
(DEFMACRO SOME-MACRO ()
(MAKE-A-FORM-WITH SOME-DATA-STRUCTURE)))
To do what I want in the second case I must do this:
(LET ((SOME-DATA-STRUCTURE (MAKE-SOME-DATA-STRUCTURE)))
(SETF (MACRO-FUNCTION 'SOME-MACRO)
#'(LAMBDA (FORM ENVIRONMENT
(DECLARE (IGNORE FORM ENVIRONMENT))
(MAKE-A-FORM-WITH SOME-DATA-STRUCTURE)))))
Furthermore, in order to implement this restriction I must introduce a
new special form, such as that used in Spice Lisp, to force a form to
be evaluated in the null lexical environment. Thus it is impossible
to live up to the suggestion in the implementation note on p.58, that
macros should not expand into implementation-dependent special forms.
This is a good point which I overlooked. It looks like this special
form must become a part of the language, not because users need to use
it directly, but becuase some macros must expand into it.
It is obvious to me why the expansion functions defined by MACROLET
must have this restriction; there is no environment at macroexpansion
time to which they can refer. The expansion functions created by
DEFMACRO, on the other hand, are not really very different from
ordinary functions created by DEFUN.
There is one difference, but it is outside the scope of the Common
Lisp definition. Most (i.e. all) implementations of Common Lisp cause
macros defined by DEFMACRO to be available for use while compiling the
file in which they are defined. This is not required by the Common
Lisp definition, but is part of the Lisp tradition.
This is not true, see the bottom of p146 "If the compiler encounters a
DEFMACRO..." It seems pretty clear that this *must* be part of the
definition, since the programmer must make sure that her macros are
defined before she uses them. If you require an explicit EVAL-WHEN,
then nearly every program I have ever written would have to be changed.
It should be obvious that this is only possible for macro
definitions which occur at "top level." For example, it would be
incorrect in this example to define THIS-MACRO at compile time:
(WHEN SOME-CONDITION
(DEFMACRO THIS-MACRO ()
(EXPAND-INTO-SOMETHING)))
In my previous discussion of "top level forms", I explained why I also
don't agree with this. The notion of a "top level form" just doesn't
belong in a lexical Lisp. Implicit compiler evaluation such as
putting DEFMACRO definitions in the compiler environment should happen
no matter where the form appears.
Similarly, any macro definition which refers to a lexically visible
entity cannot be defined at compile time, since it cannot be a "top
level" form.
It seems to me that you are arguing much more effectively for the null
DEFMACRO environment than you are arguing against the implicit
evaluation. It is clear that they are mutually exclusive.
Rob
∂03-May-86 1933 Larry←Masinter.PARC@Xerox.COM Re: MACROLET & FUNCTION
Received: from XEROX.COM by SU-AI.ARPA with TCP; 3 May 86 19:33:22 PDT
Received: from Burger.ms by ArpaGateway.ms ; 03 MAY 86 19:34:23 PDT
Sender: "Larry←Masinter.PARC"@Xerox.COM
Date: 3 May 86 19:33:20 PDT (Saturday)
Subject: Re: MACROLET & FUNCTION
From: Masinter.PARC@Xerox.COM
To: yuasa@kurims.kurims.kyoto-u.junet.Arpa
cc: Common-Lisp@SU-AI.Arpa
In-Reply-to: yuasa%kurims.kurims.kyoto-u.junet:ARPA:Xerox's message of 2
May 86 05:49
Message-ID: <860503-193423-3089@Xerox>
there's another possibility, which is
[c] (MACROLET ((FOO ...)) (FUNCTION FOO))
== (FUNCTION FOO)
i.e., MACROLET redefinitions are not seen by FUNCTION, but (FUNCTION
FOO) always refers to either the FLET or LABELS definition of FOO or
else the global definition.
(I have a definition of MACROLET which does this; I'm not willing to
argue that it is better than the others, but it is at least as
consistent.)
∂05-May-86 1555 JVC@SU-SCORE.ARPA loop where?
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 5 May 86 15:55:29 PDT
Date: Mon 5 May 86 15:55:55-PDT
From: Janet Coursey <JVC@SU-SCORE.ARPA>
Subject: loop where?
To: common-lisp@SU-AI.ARPA
Message-ID: <12204364397.39.JVC@SU-SCORE.ARPA>
I need a public domain LOOP macro or FOR or general iterative
construct to help translate zetalisp and interlisp to commonlisp.
I was told that before I (recently) began reading this list such a
request was made and answered. Please send me mail if you kept a copy
or know from whence I can ftp or otherwise obtain it. Sincerely,
Janet Coursey jvc@su-score
-------
∂05-May-86 1601 Gregor.pa@Xerox.COM Re: Lexical references in DEFMACRO
Received: from XEROX.COM by SU-AI.ARPA with TCP; 5 May 86 16:00:33 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 MAY 86 16:01:36 PDT
Date: 5 May 86 15:25 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: Lexical references in DEFMACRO
In-reply-to: edsel!sunvalleymall!eb@su-navajo.arpa (Eric Benson)'s
message of Fri, 2 May 86 16:27:58 pdt
To: edsel!sunvalleymall!eb@su-navajo.arpa
cc: Common-Lisp@su-ai.arpa
Message-ID: <860505-160136-4065@Xerox>
Another problem with having the lexical environment of a defmacro'd
macro be the null environment is that you can't "macroize for speed" the
following perfecly reasonable coding style:
(let ((unique-id "foo"))
(defun make-foo () (list unique-id () () ()))
(defun foo-p (x) (and (listp x) (eq (car x) unique-id))))
Specifically, you couldn't turn the defun of foo-p into the seemingly
obvious defmacro.
∂05-May-86 1706 Moon@SAPSUCKER.SCRC.Symbolics.COM Re: Lexical references in DEFMACRO
Received: from [192.10.41.223] by SU-AI.ARPA with TCP; 5 May 86 17:06:38 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 15353; Mon 5-May-86 20:04:32 EDT
Date: Mon, 5 May 86 20:04 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Re: Lexical references in DEFMACRO
To: Common-Lisp@SU-AI.ARPA
In-Reply-To: <860505-160136-4065@Xerox>
Message-ID: <860505200405.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 5 May 86 15:25 PDT
From: Gregor.pa@Xerox.COM
Another problem with having the lexical environment of a defmacro'd
macro be the null environment is that you can't "macroize for speed" the
following perfecly reasonable coding style:
(let ((unique-id "foo"))
(defun make-foo () (list unique-id () () ()))
(defun foo-p (x) (and (listp x) (eq (car x) unique-id))))
Specifically, you couldn't turn the defun of foo-p into the seemingly
obvious defmacro.
I think if you actually write out the seemingly obvious defmacro, you
will see that it's not so:
(defmacro foo-p (x) `(and (listp ,x) (eq (car ,x) unique-id))))
which does not reference unique-id as a variable from the body of
the macro, only from the expansion of the macro.
Of course the inline proclamation was made to order for this. I wonder
if it was intended to work for things not at top level. This can of
worms should not be dealt with piecemeal.
∂05-May-86 2159 sridhar%tekecs%tektronix.csnet@CSNET-RELAY.ARPA Help in writing infix macro in CL.
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 5 May 86 21:59:43 PDT
Received: from tektronix by csnet-relay.csnet id ab22348; 6 May 86 0:45 EDT
Received: by tektronix.TEK (5.31/6.10)
id AA12247; Mon, 5 May 86 16:35:36 PDT
Received: by tekecs.TEK (5.16/)
id AA21173; Mon, 5 May 86 16:27:48 PDT
From: "S. Sridhar" <sridhar%tekecs%tektronix.csnet@CSNET-RELAY.ARPA>
Message-Id: <8605052327.AA21173@tekecs.TEK>
Date: Mon, 5 May 86 16:27:46 PDT
To: common-lisp@su-ai.ARPA
Subject: Help in writing infix macro in CL.
Is there a way to do the following using the reader macro functions
of CLtL ?
I want to have a reader macro that translates
(a + b) to (+ a b). How can I remember the lisp object that was read
before the macro character #\+.
I would appreciate some pointers.
-sridhar
∂05-May-86 2232 MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA A proposal
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 5 May 86 22:31:44 PDT
Received: from umass-cs by csnet-relay.csnet id bc22579; 6 May 86 1:16 EDT
Date: Mon, 5 May 86 14:47 EST
From: MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA
To: common-lisp@su-ai.ARPA
Subject: A proposal
A major goal of Common-Lisp standardization is
to make it possible to be able to write a system, and
have that system run on any machine that runs common-lisp.
Given this goal, The language should provide an easy
way of packaging (no pun intended) up a system,
such that it can be
easily moved onto another machine. The package system
provides a nice way to seperate out your system from
anything existing on a machine, but I think most people
would agree it is a pain when it comes
to development. This is because a system of any size
is generally broken into many files, and while developing,
you don't necessarily load them all in, and in
the "proper" order, before working on the some part of
the system. Now many might say that dealing with this is
an "enviornment issue", or sloppy programmer practice,
such that you or your machines software
should provide you with ways to deal with these problems.
While portability is the major concern, let us not forget that another
benefit of standardization is that programmers can
move to another project, company, or system and
not have to learn an vastly different enviornment.
Another problem that arises with multiple files, is compiling them,
such that some files needed to be loading before others, to get
macros and functions defined.
It appears that common-lisp is more oriented to
dealing with single files, rather than a system with a group of them. The
MODULES stuff is a pretty weak attempt, and seems more oriented
towards a user of systems, rather than the systems themselves.
Therefore, I think that we should seriously consider including something
like the DEFSYSTEM of Zetalisp. Now, I think Zetalisp's defsystem, while
very powerful, it's fairly complicated, has horrible syntax, and isn't quite
the right thing. It think the defsystem we want should include
file interface information that is currently dispersed through all the
files of the system.
The proposal is to have something like defsystem that would define
the files, compile and load dependancies,
packages to be created, the import and exporting of symbols within those
packages. A file can indicate which part of the system it is.
Using the Defsystem information, the
file itself wouldn't need to include it all. Thus a file could have
something like:
(In-System "Robot" "Motor-Control")
Which would indicate that this is module Motor-Control of the Robot system.
Using the system information, your would know which package the file should
be in. If the system information wasn't loaded, it would load it in, creating
the package with all it's importing, exporting, shawdowing, etc. If files
needed to be loaded before this one, it could either load them in, or
maybe ask you if you want it to, or at least Warn you that they haven't
been loaded. This way, while developing you wouldn't lose.
This avoids having to have all that information redundantly specified
in all the files. Most programmer do all of this by hand, so why not
let the system doit. A software system could also provide other
"Enviornment" tools, like letting you know what needs to be recompiled,
making it easy to add imports and exports of symbols, nice display
of file/module dependancies, etc.
As far as compiling, again the system information could be consulted on
an individual file basis. As with Zetalisp defsystem, you only need
to say something like (MAKE-SYSTEM "ROBOT" :COMPILE) to have it do
all the files, with all their dependancies. When you went to move
the system to another machine, all the information would be
in the defsystem, so if you need to change the name of packages, you
would only need to do it there. It would also be a good place
to put #+ReadTime conditionals, so you would only include files/modules
for particular software systems.
I may be wrong, but it seems most groups doing development
have something similiar that they use already.
I would be more than willing to write up a concrete proposal, and code
up a portable version of it for testing, if the community is
going to take it seriously.
Kelly Murray
University of Massachusetts
∂06-May-86 0555 FAHLMAN@C.CS.CMU.EDU Help in writing infix macro in CL.
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 6 May 86 05:55:42 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 6 May 86 08:53:04-EDT
Date: Tue, 6 May 1986 08:52 EDT
Message-ID: <FAHLMAN.12204516780.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "S. Sridhar" <sridhar%tekecs%tektronix.csnet@CSNET-RELAY.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Help in writing infix macro in CL.
In-reply-to: Msg of 5 May 1986 19:27-EDT from S. Sridhar <sridhar%tekecs%tektronix.csnet at CSNET-RELAY.ARPA>
I don't think that you can write an infix reader just by defining new
character macros for #\+ and friends. This new reader needs to get at
the whole expression, either because it is caled directly by your
program or because it is invoked when you see that first #\(, assuming
that all your top-level expressions are parenthesized. Of course, the
new reader can be built using the old one, or more specialized built-in
functions, to do most of the work, but it can't wait until you hit an
infix operator before it gets invoked.
-- Scott
∂06-May-86 0658 DLW@SAPSUCKER.SCRC.Symbolics.COM Why we should not try to add programming environments to the Common Lisp standard
Received: from [192.10.41.223] by SU-AI.ARPA with TCP; 6 May 86 06:58:18 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 15541; Tue 6-May-86 09:56:43 EDT
Date: Tue, 6 May 86 10:01 EDT
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Why we should not try to add programming environments to the Common Lisp standard
To: MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: The message of 5 May 86 15:47 EDT from MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA
Message-ID: <860506100109.0.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Mon, 5 May 86 14:47 EST
From: MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA
While portability is the major concern, let us not forget that another
benefit of standardization is that programmers can
move to another project, company, or system and
not have to learn an vastly different enviornment.
This is an argument in favor of developing a standardized programming
environment.
One reason that Common Lisp came into existence was a widespread feeling
that a group of us pretty much agreed on what Lisp is, or should be, and
that it was time to consolidate and standardize on what we already
understood. Language features that we felt were still under active
development, and were not yet well understood, stable, and agreed upon,
were omitted.
I believe that there is general agreement that most programming
environment facilities are still in the state of active development;
there is not a widespread concensus about how they should work.
Therefore, adoping them as part of the actual Common Lisp standard is
not appropriate yet.
However, this is one of the reasons for the concept of the "yellow
pages" library of shared, portable programs. Such facilities can be
placed into this library and made widely available. If experimentation,
time, and experience lead to a broad concensus, then it's time to
consider promoting the program to "white pages" status. I presume that
the steering and/or technical committees will produce an official policy
statement about this at some point.
Now, I think Zetalisp's defsystem, while
very powerful, it's fairly complicated, has horrible syntax, and isn't quite
the right thing.
By the way, the Software Products department of Symbolics agrees with
this. Release 7 will have a completely redesigned facility that is
simpler, has greatly improved syntax, and is closer to the right thing.
It's called the "system construction tool", and was mentioned in the
Release 7 announcement a couple of weeks ago. The reason I bring this
up is to show that things are still in a state of active development,
and too volatile to be cast in the concrete of the Common Lisp
specification.
∂06-May-86 0709 DCP@SAPSUCKER.SCRC.Symbolics.COM Re: Lexical references in DEFMACRO
Received: from [192.10.41.223] by SU-AI.ARPA with TCP; 6 May 86 07:08:48 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 15550; Tue 6-May-86 10:07:06 EDT
Date: Tue, 6 May 86 10:05 EDT
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: Re: Lexical references in DEFMACRO
To: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>, Common-Lisp@SU-AI.ARPA
In-Reply-To: <860505200405.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <860506100516.4.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Mon, 5 May 86 20:04 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Date: 5 May 86 15:25 PDT
From: Gregor.pa@Xerox.COM
Another problem with having the lexical environment of a defmacro'd
macro be the null environment is that you can't "macroize for speed" the
following perfecly reasonable coding style:
(let ((unique-id "foo"))
(defun make-foo () (list unique-id () () ()))
(defun foo-p (x) (and (listp x) (eq (car x) unique-id))))
Specifically, you couldn't turn the defun of foo-p into the seemingly
obvious defmacro.
I think if you actually write out the seemingly obvious defmacro, you
will see that it's not so:
(defmacro foo-p (x) `(and (listp ,x) (eq (car ,x) unique-id))))
which does not reference unique-id as a variable from the body of
the macro, only from the expansion of the macro.
',unique-id
Of course the inline proclamation was made to order for this. I wonder
if it was intended to work for things not at top level. This can of
worms should not be dealt with piecemeal.
This can of worms includes storing FOOs in binary files. The string
which is unique-id, by Gregor's intended semantics, must be the same
in all bin files that have their roots with the make-foo above, and the
loader somehow has to know all this. It might work in a single file,
but to do multiple files starts getting into the realm of global unique
ids and databases and so on.
∂06-May-86 0713 DCP@SAPSUCKER.SCRC.Symbolics.COM Help in writing infix macro in CL.
Received: from [192.10.41.223] by SU-AI.ARPA with TCP; 6 May 86 07:13:31 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 15557; Tue 6-May-86 10:11:55 EDT
Date: Tue, 6 May 86 10:09 EDT
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: Help in writing infix macro in CL.
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>,
S. Sridhar <sridhar%tekecs%tektronix.csnet@CSNET-RELAY.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12204516780.BABYL@C.CS.CMU.EDU>
Message-ID: <860506100944.5.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Tue, 6 May 1986 08:52 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I don't think that you can write an infix reader just by defining new
character macros for #\+ and friends. This new reader needs to get at
the whole expression, either because it is caled directly by your
program or because it is invoked when you see that first #\(, assuming
that all your top-level expressions are parenthesized. Of course, the
new reader can be built using the old one, or more specialized built-in
functions, to do most of the work, but it can't wait until you hit an
infix operator before it gets invoked.
In Zetalisp and Symbolics Common Lisp (and probably other MIT-derived
LispM dialects), there is a sharp-sign macro (altmode/lozenge) that
invokes the infix reader. Therefore (lozenges changed to dollar signs):
(equal '#$ a+b $ '(+ a b)) => T
∂06-May-86 0716 NGALL@G.BBN.COM Re: Help in writing infix macro in CL.
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 6 May 86 07:16:13 PDT
Date: 6 May 1986 10:17-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: Help in writing infix macro in CL.
From: NGALL@G.BBN.COM
To: sridhar%tekecs%tektronix.csnet@RELAY.CS.NET
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM] 6-May-86 10:17:38.NGALL>
In-Reply-To: <8605052327.AA21173@tekecs.TEK>
Date: Mon, 5 May 86 16:27:46 PDT
From: "S. Sridhar" <sridhar%tekecs%tektronix.csnet@CSNET-RELAY.ARPA>
To: common-lisp@su-ai.ARPA
Subject: Help in writing infix macro in CL.
Message-ID: <8605052327.AA21173@tekecs.TEK>
Is there a way to do the following using the reader macro functions
of CLtL ?
I want to have a reader macro that translates
(a + b) to (+ a b). How can I remember the lisp object that was read
before the macro character #\+.
I would appreciate some pointers.
-sridhar
--------------------
As Scott pointed out, there is no way in CL to access what has been
read prior to the execution of a read-macro. To do what you want, you
would have to redefine the read-macro for #\( to save the elements
seen so far in a list that is manipulatable via a global variable. A
less ambitious approach might be to use [...] around infix
expressions; then you wouldn't have to worry about breaking (...).
-- Nick
∂06-May-86 0741 kempf%hplabsc@hplabs.ARPA Re: A proposal
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 6 May 86 07:40:25 PDT
Received: from hplabsc by hplabs.ARPA ; Tue, 6 May 86 07:40:31 pdt
Received: by hplabsc ; Tue, 6 May 86 07:40:41 pdt
Date: Tue, 6 May 86 07:40:41 pdt
From: Jim Kempf <kempf%hplabsc@hplabs.ARPA>
Message-Id: <8605061440.AA03317@hplabsc>
To: MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA, common-lisp@su-ai.ARPA
Subject: Re: A proposal
My experience with using Common Lisp for software engineering is
that it is less than ideal. As Kelly outlined in his note, the
package system and provide-require are just insufficient for
keeping track of dependencies in a large system. I think a
properly structured DEFSYSTEM construct would certainly be
of benefit; however, whether that should be part of the environment
or part of the language is another question. Perhaps we need
a standard environment (like U*nix) as well?
In addition to the problem with large scale system building, the
lack of seperation between a function interface and its implementation
(such as occurs in Mesa and Ada) makes modification of software
components in a large system difficult. The DECLARE facility is,
again, insufficient, as are most object oriented dialects. DECLARE
bundles the interface and implementation into one thing (the
DEFUN), while most object oriented dialects allow (potentially
untyped) parameters to messages, and hence suffer from the same
problem as DECLARE-DEFUN. While a construct to aid seperation of
function/message interfaces and implementations would help
in large scale systems building, it may hamper the use of
Common Lisp as a prototyping language, unless constructed so
that a smooth transition between prototyping and production
were possible.
Jim Kempf hplabs!kempf
∂06-May-86 1049 Gregor.pa@Xerox.COM Re: Lexical references in DEFMACRO
Received: from XEROX.COM by SU-AI.ARPA with TCP; 6 May 86 10:49:12 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 MAY 86 10:46:53 PDT
Date: 6 May 86 10:46 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: Lexical references in DEFMACRO
In-reply-to: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>'s message of
Mon, 5 May 86 20:04 EDT
To: Moon@SCRC-STONY-BROOK.arpa
cc: Common-Lisp@SU-AI.ARPA
Message-ID: <860506-104653-4711@Xerox>
I thought the obvious defmacro was:
(defmacro foo-p (x) `(and (listp ,x) (eq (car ,x) ',unique-id))))
which is the lexically binding of unique-id I had in mind. I will try
not to be so terse next time.
∂06-May-86 1104 MATHIS@USC-ISIF.ARPA X3J13 Approval
Received: from USC-ISIF.ARPA by SU-AI.ARPA with TCP; 6 May 86 11:02:54 PDT
Date: 6 May 1986 11:04-PDT
Sender: MATHIS@USC-ISIF.ARPA
Subject: X3J13 Approval
From: MATHIS@USC-ISIF.ARPA
To: Common-Lisp@SU-AI.ARPA
Message-ID: <[USC-ISIF.ARPA] 6-May-86 11:04:44.MATHIS>
X3J13, the Technical Committee for the standardization of Common
Lisp, has been approved. The first meeting will be September 23
and 24, 1986, at CBEMA in Washington, DC. I am serving as
convenor of that first meeting. I am also planning to have
further information available at the Lisp Conference in Boston,
August 4-6, 1986.
I have sent another message (with the subject "Lisp
Standardization") to everyone who has expressed interest in the
standards process. I will continue to send general information
to the whole Common Lisp Community, but most of the stuff about
X3J13 will go to this other more specialized list. If you (or
your company) are interested in X3J13, please let me know. I can
also be reached at 9712 Ceralene Drive, Fairfax, Virginia
22032-1704 or (703)425-5923.
-- Bob Mathis
∂06-May-86 1202 Moon@SAPSUCKER.SCRC.Symbolics.COM Re: Lexical references in DEFMACRO
Received: from [192.10.41.223] by SU-AI.ARPA with TCP; 6 May 86 12:02:31 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 15762; Tue 6-May-86 14:59:41 EDT
Date: Tue, 6 May 86 14:58 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Re: Lexical references in DEFMACRO
To: Gregor.pa@Xerox.COM
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <860506-104653-4711@Xerox>
Message-ID: <860506145832.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 6 May 86 10:46 PDT
From: Gregor.pa@Xerox.COM
I thought the obvious defmacro was:
(defmacro foo-p (x) `(and (listp ,x) (eq (car ,x) ',unique-id))))
which is the lexically binding of unique-id I had in mind. I will try
not to be so terse next time.
I see. I think I had a momentary brain failure in which I thought Common
Lisp non-top-level DEFUN was intended to work like Scheme DEFINE.
I think what's underlying all of this is that the provisions for non-top-level
definitions in current Common Lisp are ill-thought-out and probably inconsistent.
I don't recall the discussions predating the publication of the manual spending
a lot of time on these issues. Getting this resolved, and a language definition
that we can all agree is useful, makes sense, and is implementable, is something
the new standardization and language cleanup process that is starting is going
to have to attack. Your example is one more example of a problem with the
current half attempt at non-top-level definitions that's going to have to be
considered.
∂06-May-86 1755 GSB@MC.LCS.MIT.EDU loop where?
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 6 May 86 17:50:26 PDT
Date: Tue, 6 May 86 20:52:09 EDT
From: "Glenn S. Burke" <GSB@MC.LCS.MIT.EDU>
Subject: loop where?
To: JVC@SU-SCORE.ARPA
cc: common-lisp@SU-AI.ARPA
Message-ID: <[MC.LCS.MIT.EDU].905569.860506.GSB>
I recently (less than a week ago) converted the source of LOOP used in
NIL (shared source with Zetalisp, but a bit more developed) to Common
Lisp, and have it running in DEC VAXLISP at Palladian.
When it has been demonstrated to be fairly stable, I will make it
available, probably by anonymous FTP off of MC.
This is not intended to comprise any "development" of LOOP. It is a
conversion only, and is intended to be the official Common-Lisp
version of NIL/Zetalisp LOOP.
It is of course missing the iteration paths for hash tables and
packages, since they are rather implementation dependent.
∂06-May-86 2341 RAM@C.CS.CMU.EDU Re: Lexical references in DEFMACRO
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 6 May 86 23:41:27 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Wed 7 May 86 02:42:22-EDT
Date: Wed, 7 May 1986 02:42 EDT
Message-ID: <RAM.12204711448.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Re: Lexical references in DEFMACRO
(let ((unique-id "foo"))
(defun make-foo () (list unique-id () () ()))
(defmacro foo-p (x) `(and (listp ,x) (eq (car ,x) ',unique-id))))
Although this macro may be obvious, it is non-obvious how it could be
implemented, supposing that it was legal. Given that macros are
expanded at compile time, our only choice would be to compute the
lexical environment of the macro at compile time, i.e. eval an
arbitrary amount of code surrounding the DEFMACRO.
If we really believe that macros are just like functions, then we would
conclude that the macro and the function must close over the *same*
variable, despite that fact that the variable must first exist in the
compiler. The only way that this could possibly work would be for the
compiler to create the closure variable at compile time, and then
arrange for it to be shared between all of the lisps which load the
resulting binary; this is a neat trick.
I think that the real problem is that macros and functions are
fundamentally different; simplistic attempts to draw paralells between
them will just result in confusion.
Rob
∂07-May-86 0429 GJC@MC.LCS.MIT.EDU infix madness
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 7 May 86 04:28:59 PDT
Date: Wed, 7 May 86 07:30:45 EDT
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Subject: infix madness
To: common-lisp@SU-AI.ARPA
Message-ID: <[MC.LCS.MIT.EDU].905947.860507.GJC>
And if you really want to go for it I can supply a version of the Famous CGOL
lisp-front-end parser. It also defines a #$ readmacro, but likes to work
mostly by creating a readtable such that all non-whitespace characters
do an unread-char and then call CGOL-PARSE. CGOL source files then have
an (eval-when (eval compile) (setq *readtable* *cgol-readtable*)) in
the front, so that they really prefer that LOAD is defined as
(DEFUN LOAD (...) (LET ((*READTABLE* *READTABLE*)) .....))
∂07-May-86 1355 Bobrow.pa@Xerox.COM Re: A proposal
Received: from XEROX.COM by SU-AI.ARPA with TCP; 7 May 86 13:54:46 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 07 MAY 86 13:53:52 PDT
Date: 7 May 86 13:53 PDT
From: Bobrow.pa@Xerox.COM
Subject: Re: A proposal
In-reply-to: MURRAY@umass-cs.CSNET's message of Mon, 5 May 86 14:47 EST
To: MURRAY%umass-cs.CSNet@CSNet-Relay.ARPA
cc: common-lisp@su-ai.ARPA
Message-ID: <860507-135352-1849@Xerox>
I agree that a DEFSYSTEM facility is useful. However, what its specs
should be are unclear. We just built an experimental system** using
objects that also supports incremental changes as well as version
control. Should facilities like these be included? It seems that we
are far from having a good handle on what is needed. This is to support
Dan Weinreb's contention that the system construction tool business is
still very volatile.
(** A copy of a short paper on defintion groups is available on
request. Send Snail-mail address.)
∂07-May-86 1741 KMP@SCRC-STONY-BROOK.ARPA [JAR@MC.LCS.MIT.EDU: Problems with packages]
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 7 May 86 17:41:16 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 482294; Wed 7-May-86 14:20:05-EDT
Date: Wed, 7 May 86 14:20 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: [JAR@MC.LCS.MIT.EDU: Problems with packages]
To: Common-Lisp@SU-AI.ARPA
Message-ID: <860507142048.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Return-path: <@MIT-MC.ARPA:JAR@MC.LCS.MIT.EDU>
Received: from MC.LCS.MIT.EDU (MIT-MC.ARPA) by SCRC-STONY-BROOK.ARPA via INTERNET with SMTP id 481541; 6 May 86 16:22:38-EDT
Date: Tue, 6 May 86 16:25:07 EDT
From: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
Subject: Problems with packages
To: KMP@SCRC-STONY-BROOK.ARPA
In-reply-to: Msg of Thu 1 May 86 22:53 EDT from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
Message-ID: <[MC.LCS.MIT.EDU].905392.860506.JAR>
Funny, I've been running into these same problems myself recently.
Shadowing just doesn't work very well.
One interesting glitch I cam across is that it's desirable to be able to
say "use all symbols from package FOO except for X" but there's no way
to say so. It doesn't work to shadow X if you want to inherit X from
some other package. It doesn't work to enumerate the symbols you want
from FOO because it might be very large (e.g. FOO = LISP). Is there any
3600 feature which lets one do this? (:USE ((FOO :EXCEPT (BAR BAZ)) FOO2))
In T and MIT Scheme shadowing isn't a problem because it works
retroactively.
Jonathan.
∂09-May-86 0928 DCP@SAPSUCKER.SCRC.Symbolics.COM format ~nC
Received: from [192.10.41.223] by SU-AI.ARPA with TCP; 9 May 86 09:28:13 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 17318; Fri 9-May-86 12:25:38 EDT
Date: Fri, 9 May 86 12:24 EDT
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: format ~nC
To: common-lisp@SU-AI.ARPA
Message-ID: <860509122416.6.DCP@FIREBIRD.SCRC.Symbolics.COM>
Is there a good reason ~C doesn't take an arg? I just naively tried
(format t "~&~VC~VC~%" count-1 char-1 count-2 char-2)
and was rewarded with one occurance of each character each time; the
counts had been thrown away. ~~ takes an arg.
∂09-May-86 1137 robbins%bach.decnet@hudson.dec.com RE: format ~nC
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 9 May 86 11:36:35 PDT
Date: 9 May 86 14:39:00 EST
From: "BACH::ROBBINS" <robbins%bach.decnet@hudson.dec.com>
Subject: RE: format ~nC
To: "common-lisp" <common-lisp@su-ai.arpa>
Reply-To: "BACH::ROBBINS" <robbins%bach.decnet@hudson.dec.com>
---------------------Reply to mail dated 9-MAY-1986 12:58---------------------
>Is there a good reason ~C doesn't take an arg? I just naively tried
> (format t "~&~VC~VC~%" count-1 char-1 count-2 char-2)
>and was rewarded with one occurance of each character each time; the
>counts had been thrown away. ~~ takes an arg.
The FORMAT directives that output a constant character (~~, ~%, ~&, and ~|)
take a count prefix parameter and use up no arguments. The ~C directive
is more like ~A, ~S, ~G etc., these all output some representation of the
next argument in the call to FORMAT and none of them take a count parameter.
Is that a good reason? Hmm...
-- Rich
------
∂10-May-86 0928 tansei!a37078%utokyo-relay.csnet@CSNET-RELAY.ARPA The first note on kanji, sent to junet site in Jan 1986 and some reactions in japan
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 10 May 86 09:28:44 PDT
Received: from utokyo-relay by csnet-relay.csnet id ab07051; 10 May 86 12:27 EDT
Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA22322; Sat, 10 May 86 12:47:21+0900
Received: by tansei.utyo.junet (4.12/4.9J)
id AA08572; Sat, 10 May 86 12:30:08+0900
Date: Sat, 10 May 86 12:30:08+0900
From: Masayuki Ida <tansei!a37078%utokyo-relay.csnet@CSNET-RELAY.ARPA>
Message-Id: <8605100330.AA08572@tansei.utyo.junet>
To: common-lisp@SU-AI.ARPA, ida@UTOKYO-RELAY.CSNET, mathis@USC-ISIF.ARPA
Subject: The first note on kanji, sent to junet site in Jan 1986 and some reactions in japan
I am preparing a ducument on Kanji standard in japan for Common Lisp.
The concepts in it is quite natural to Common Lisp, I think.
But, I want to have opinions and advices from many persons as possible.
The key ideas are follows;
1) include japanese-char data type and normalized-string data type.
Japanese-char type is a class for JIS 6226, and is a subtype of string-char.
(physically, JIS 6226 char occupies 2 byte each.)
Normalized-string type is a subtype of the string type, and its component characters
are of japanese-char type characters.
NOT-normalized string may contain japanese-char and other char randomly.
2) include string-normalize, normalized-string-p, and japanese-char-p at least.
3) char-code-limit should be greater than 16 bit to hold japanese-char character.
char-bits-limit has not always meaningfull for japanese-char.
4) length function invocation with japanese-char strings must return
its apparent length, not the storage length.
I think the above idea will cope with various implementations
including the usual english-text-only systems.
If you have an idea to discuss, please let me know
Thank you.
Masayuki ida
junet: ida@ccut.u-tokyo.junet
Csnet/arpanet: ida%utokyo-relay.csnet@csnet-relay
--------------------- follwoing is the reaction to the above message --------
1) Prof. Kigen Hasebe told me that there is a kind of standard for AT&T UNIX.
2) Dr. Morisaki of NTT told me that MIT LCS had an experience to cope with
japanese characters on their NIL in 1984 already.
Several Common-lisp(-like) implementations told me that they have facility
to cope with japanese characters with much the same idea I described above.
At Jeida, the working group for japanese character handling in Common Lisp
started at the last april.
∂10-May-86 1954 RAM@C.CS.CMU.EDU New type specifier?
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 10 May 86 19:54:41 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Sat 10 May 86 22:55:48-EDT
Date: Sat, 10 May 1986 22:55 EDT
Message-ID: <RAM.12205718776.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: New type specifier?
I propose adding a new type specifier, VOID. It is subject to the
same constraints as the VALUES specifier, and is used in a similar
way. (THE VOID xxx) indicates that it is an error to use the value(s)
of xxx, but the actual expression might evaluate to any number of
values of any type. This can also be used for
(FUNCTION foo (...) VOID), to indicate that the function has no
meaningful value.
Note that this is not the same as the NIL specifier (not to be
confused with NULL). (THE NIL xxx) is always erroneous, since no
expression can evaluate an object of type NIL. It has also been
suggested that (VALUES) be used when no useful value is returned. The
problem with this is that it is not erroneous for code to expect
values when there are none, so the compiler cannot give an error
message.
Rob
∂11-May-86 1356 RWK@SAPSUCKER.SCRC.Symbolics.COM The first note on kanji, sent to junet site in Jan 1986 and some reactions in japan
Received: from [192.10.41.223] by SU-AI.ARPA with TCP; 11 May 86 13:56:26 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 17749; Sun 11-May-86 16:53:31 EDT
Date: Sun, 11 May 86 16:51 EDT
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
Subject: The first note on kanji, sent to junet site in Jan 1986 and some reactions in japan
To: Masayuki Ida <tansei!a37078%utokyo-relay.csnet@CSNET-RELAY.ARPA>
cc: common-lisp@SU-AI.ARPA, ida%UTOKYO-RELAY.CSNET@CSNET-RELAY.ARPA,
mathis@USC-ISIF.ARPA
In-Reply-To: <8605100330.AA08572@tansei.utyo.junet>
Supersedes: <860511165045.5.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Message-ID: <860511165153.6.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
[Please note: the character system I refer to as our
"current" implementation is new, and will be released
to customers this fall as part of Release 7.0 of our
software.]
Date: Sat, 10 May 86 12:30:08+0900
From: Masayuki Ida <tansei!a37078%utokyo-relay.csnet@CSNET-RELAY.ARPA>
I am preparing a ducument on Kanji standard in japan for Common Lisp.
The concepts in it is quite natural to Common Lisp, I think.
But, I want to have opinions and advices from many persons as possible.
The key ideas are follows;
1) include japanese-char data type and normalized-string data type.
Japanese-char type is a class for JIS 6226, and is a subtype of string-char.
(physically, JIS 6226 char occupies 2 byte each.)
Make it a subtype of EXTENDED-STRING-CHAR instead. Or just
CHARACTER. Because the character codes are two bytes long,
many systems may wish to make their normal strings only hold
"ordinary" characters (i.e. what are currently called
string-char). What you are proposing here is an incompatible
change to STRING-CHAR, and I don't believe it is really
necessary.
In our implementation, Japanese characters are SUBTYPEP of CHARACTER.
STRING-CHAR's are characters that can be stored in ANY string.
We have special strings that can hold ANY character (the type is,
appropriately enough, STRING)
Normalized-string type is a subtype of the string type, and its component characters
are of japanese-char type characters.
This is an extremely poor choice of names for this type. Besides,
you're getting into specifying the implementation.
NOT-normalized string may contain japanese-char and other char randomly.
What about implementations which have no wish to make their usual
strings huge to support Japanese? Since Japanese characters take
two bytes, we're talking a minimum of three bytes per character.
Implementations with a lot of documentation strings will find the
cost of that documentation suddenly tripled. (Actually, you can
do it with less, because Kanji does not actually need the full 2↑16
codes. The rest of the languages (except things like Chinese) are
small enough to fit in at the end, or the start, or wherever the
implementation chooses. (Remember, CL never specifies the character
codes for individual characters, just their meaning).
2) include string-normalize, normalized-string-p, and japanese-char-p at least.
I take it string-normalize takes a string and generates a more compact
representation? There's nothing wrong with that, and perhaps "normalize"
is the right word here. However, specifying Japanese as the single and
sole type that is "normalized" to is rather ungeneral. I don't think
ANY string type should be named NORMALIZED, nor do I think there
should be a NORMALIZED-STRING-P predicate that determines whether
a string is of some specific type. Instead, NORMALIZED-STRING-P should
say whether STRING-NORMALIZE will, in fact, do anything, or if it will
just return its argument.
About JAPANESE-CHAR-P: I am glad to see you have not tried to
do this with the CHAR-FONT field, but rather included it into
the CHAR-CODE. This is indeed the right way to support different
character-set's, as opposed to character-styles (i.e. bold, italic,
etc). CLtL did not make it clear what CHAR-FONT is intended
for, but if you use CHAR-FONT, then you get characters which appear
to be the "same" character, even though they are in different languages.
We eventually decided that CHAR-FONT was so ill-specified as to be
useless, and do not use it for anything, and CHAR-FONT-LIMIT is 1
in our system.
3) char-code-limit should be greater than 16 bit to hold japanese-char character.
char-bits-limit has not always meaningfull for japanese-char.
In our implementation, char-code-limit is 2↑16, and it works fine.
Of course, we have provision for extending things beyond char-code-limit
as needed, but we have never needed that.
One other thing: Please do not specify any standard for the values
of CHAR-CODE belonging to specific characters. Doing so only invites
conflicts between standards for different languages. For example,
Hebrew and Arabic might easily choose the same range of values, because
the standards groups weren't talking to each other, or didn't even
know about each other. Or a standards group might choose a standard
which would make life very hard for an implementation.
Instead, specify that if these are to be written to a file, that it
be done with a stream gotten by
(OPEN PATHNAME :ELEMENT-TYPE 'EXTENDED-STRING-CHAR :DIRECTION :OUTPUT)
or
(OPEN PATHNAME :ELEMENT-TYPE 'CHARACTER :DIRECTION :OUTPUT)
Then standardize on interchange and communication formats for files.
For example, if there is an ISO standard for storing characters of
different character-sets, you might write
(OPEN PATHNAME :ELEMENT-TYPE 'EXTENDED-STRING-CHAR
:DIRECTION :OUTPUT
:FILE-DATA-FORMAT :ISO)
This leaves implementations with their own file format free to
work with that format by default. For example, our file format
allows us to do a number of things which will not be part of any
character standard, such as include diagrams, marks, etc. We
would not want to abandon our file format wholesale.
4) length function invocation with japanese-char strings must return
its apparent length, not the storage length.
Indeed!
CL has no concept of storage length. The length function must return
the number of characters, which is the number of objects that can
be accessed with ELT. I'm trying to reinforce what you're saying
here slightly. An implementation that simply stores Japanese as
pairs of characters is incorrect, even if LENGTH returns the right
number, if ELT, AREF, etc. don't give back the entire Japanese
character.
I think the above idea will cope with various implementations
including the usual english-text-only systems.
If you have an idea to discuss, please let me know
Thank you.
Masayuki ida
junet: ida@ccut.u-tokyo.junet
Csnet/arpanet: ida%utokyo-relay.csnet@csnet-relay
--------------------- follwoing is the reaction to the above message --------
1) Prof. Kigen Hasebe told me that there is a kind of standard for AT&T UNIX.
2) Dr. Morisaki of NTT told me that MIT LCS had an experience to cope with
japanese characters on their NIL in 1984 already.
I don't know about NIL. I do know that we have been supporting
Japanese characters for at least that long, and our experiences
with it are part of the motivation for the design of our current
character system.
Several Common-lisp(-like) implementations told me that they have facility
to cope with japanese characters with much the same idea I described above.
At Jeida, the working group for japanese character handling in Common Lisp
started at the last april.
∂11-May-86 1606 KMP@SCRC-STONY-BROOK.ARPA New type specifier?
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 11 May 86 16:06:32 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 485265; Sun 11-May-86 19:04:41-EDT
Date: Sun, 11 May 86 19:06 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: New type specifier?
To: RAM@C.CS.CMU.EDU
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <RAM.12205718776.BABYL@C.CS.CMU.EDU>
Message-ID: <860511190615.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Unfortunately, even if you had a VOID type specifier, it would not be
reasonable for the compiler to warn about uses of VOID items. It is only
a semantic error if you rely on the particular value that returns, not
if you use a value that happens to come back. For example, consider:
(DEFUN FOO (X)
(IF X (VALUES T 3) (VALUES NIL (THE VOID NIL))))
As I understand it, you're suggesting that this would declare that the
data-flow from the alternative branch of the IF to have a void second value.
The problem is that a program such as:
(DEFUN BAR (X)
(DECLARE (SPECIAL *FOO*))
(MULTIPLE-VALUE-BIND (A B)
(FOO X)
(SETQ *FOO* (CONS A B))
(IF (CAR *FOO*) (CDR *FOO*) NIL)))
is using B legitimately because it is never accessing the second value unless
the first value is true. The problem is that whether a value is "used" is relative,
not absolute. Consider even the program:
(DEFUN BAR (X)
(MULTIPLE-VALUE-BIND (A B)
(FOO X)
(PRINT B)
A))
Surely, you might say, if anything "uses" B, this does. But what if I tell you
now that BAR is not exported and is called internally only from BAZ, which is
defined by:
(DEFUN BAZ (X &AUX BAR-OUTPUT-IS-VALID)
(LET ((BAR-OUTPUT-AS-A-STRING
(WITH-OUTPUT-TO-STRING (*STANDARD-OUTPUT*)
(SETQ BAR-OUTPUT-IS-VALID (BAR X)))))
(IF BAR-OUTPUT-IS-VALID
BAR-OUTPUT-AS-A-STRING
NIL)))
The effect of having used the void value has been contained and is in the global
context cannot be said to have been used. I claim the output of the function BAZ
is meaningful in all situations. In the final analysis, I think the kind of error
you seek to detect is inherently undetectable for fairly deep-seated philosophical
reasons. I would be amazingly irrated if compilers became pretentious enough to
claim that understood my intent in a situation like this, since I think it's
probably possible to construct a proof that they cannot.
Your VOID specifier does have the slight advantage that it provides useful
self-documentation from me to myself about my intent in the program. It might
even prove useful to programs -writing- programs. It's just that in the general
case of reading programs, it's of little or no use in proving that a program
is incorrect because of issues related to this idea of the global vs local
relevance of a computation.
∂11-May-86 1805 RAM@C.CS.CMU.EDU New type specifier?
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 11 May 86 18:05:48 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Sun 11 May 86 21:06:24-EDT
Date: Sun, 11 May 1986 21:06 EDT
Message-ID: <RAM.12205961002.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Subject: New type specifier?
In-reply-to: Msg of 11 May 1986 19:06-EDT from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
Well, I freely admit that the big hole in my proposal is defining
what it means to "use" a VOID value. I think that the best approach
is to be extremely facist. The only places where a void expression
may be legal are:
1] Any place where the value is immediately discarded: PROGN, etc.
2] Any place in a function that can return multiple values. In
addition to tail-recursive positions, this includes the protected
form of UNWIND-PROTECT and the values form for
MULTIPLE-VALUE-PROG1 when these forms are in such a
multiple-value position.
Note that in either case, a void value may be illegal because the
result was declared to be of some other type:
(proclaim '(function frob-foo (foo) void))
(defun frob-foo (foo) ...)
(proclaim '(function make-foo ((member t nil)) foo))
(defun make-foo (frob-p)
(let ((foo (cons-a-foo)))
(if frob-p
(frob-foo foo)
foo)))
In this classic "oops, I forgot to return the value" example, the
compiler is quite justified in giving a warning, since one branch of
the IF can never be legally executed. The function MAKE-FOO itself is
not erroneous, but the compiler could replace the call to FROB-FOO
with code that just signals an error. When this happens, I would like
my compiler to tell me that something may be wrong, since there almost
certainly is.
Rob
∂11-May-86 1838 RAM@C.CS.CMU.EDU New type specifier?
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 11 May 86 18:38:10 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Sun 11 May 86 21:39:15-EDT
Date: Sun, 11 May 1986 21:39 EDT
Message-ID: <RAM.12205966982.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: New type specifier?
On second thought, it isn't true that the call to FROB-FOO would
be replaced with a call to error, since it is possible that FROB-FOO
may not return. This doesn't reduce the usefulness of getting a
warning, though. Lisp's dynamic typing makes it very difficult to
prove anything erroneous, but there are many code sequences which are
unreasonable. Compiler warnings are for flagging code which is
probably not what you want. If you write lots of declarations, you
give the compiler a better idea of what you want, so it can give
better warnings. VOID declarations give a useful increment in
specifying what I want. Judging from various discussions of (VALUES),
I think that there is demand for a way to declare "procedures" in
Common Lisp.
Rob
∂12-May-86 0621 KMP@SCRC-STONY-BROOK.ARPA Void
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 12 May 86 06:21:44 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 485357; Mon 12-May-86 06:27:47-EDT
Date: Mon, 12 May 86 06:28 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Void
To: RAM@C.CS.CMU.EDU
cc: Common-Lisp@SU-AI.ARPA
References: <RAM.12205961002.BABYL@C.CS.CMU.EDU>
Message-ID: <860512062855.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Sun, 11 May 1986 21:06 EDT
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
Well, I freely admit that the big hole in my proposal is defining
what it means to "use" a VOID value. I think that the best approach
is to be extremely facist.
I've outlined reasonable design principles which suggest this is a bogus
thing do do. I hardly find your idea of ignoring those principles and
just arbitrarily pulling a semantics out of the air to be very convincing.
The only places where a void expression may be legal are:
1] Any place where the value is immediately discarded: PROGN, etc.
2] Any place in a function that can return multiple values. In
addition to tail-recursive positions, this includes the protected
form of UNWIND-PROTECT and the values form for
MULTIPLE-VALUE-PROG1 when these forms are in such a
multiple-value position.
I'm sorry, but I find this completely ridiculous. Many valid programs can be
written which use `void' values in ways other than this without being ill-formed.
Note that in either case, a void value may be illegal because the
result was declared to be of some other type:
(proclaim '(function frob-foo (foo) void))
(defun frob-foo (foo) ...)
(proclaim '(function make-foo ((member t nil)) foo))
(defun make-foo (frob-p)
(let ((foo (cons-a-foo)))
(if frob-p
(frob-foo foo)
foo)))
Suppose that FROB-FOO puts the FOO on the heap somewhere. Then suppose that
I have a function, CREATE-FOO, which is the only call of MAKE-FOO and is
defined as:
(DEFUN CREATE-FOO (STASH-P)
(COND (PUT-IN-HEAP
(MAKE-FOO T)
(VALUES NIL NIL))
(T
(VALUES (MAKE-FOO NIL) T))))
There's nothing ill-formed about the collection of programs which include
my program and yours.
In this classic "oops, I forgot to return the value" example, the
compiler is quite justified in giving a warning, since one branch of
the IF can never be legally executed. The function MAKE-FOO itself is
not erroneous, but the compiler could replace the call to FROB-FOO
with code that just signals an error. When this happens, I would like
my compiler to tell me that something may be wrong, since there almost
certainly is.
The programming problem you're worried about is a common one, but the technique
you're proposing for fixing it is just not practical. This situation comes up
in legitimate code (especially when macros are involved) all the time.
Consider the following common situation: I have a macro MYBLOCK which binds
the variable * to the value of the previous computation at the same level.
For example:
(DEFMACRO MYBLOCK (&BODY FORMS)
`(LET ((* *))
,@(MAPCAR #'(LAMBDA (FORM) `(SETQ * ,FORM)) FORMS)))
This lets me do:
(MYBLOCK 3 (+ * 5) (- * 2)) ==> 6
But what if the function FOO has a void return value? It's completely
reasonable to do:
(MYBLOCK (FOO) (BAR) (PRINT *))
because * gets assigned but never used.
The way the program can represent the information necessary to decide whether a
value is used correctly are endless. You really cannot mechanically detect them.
∂12-May-86 1100 @MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU First Class environments in CL ??
Received: from MIT-LIVE-OAK.ARPA by SU-AI.ARPA with TCP; 12 May 86 11:00:34 PDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 1286; 12 May 86 14:01:08-EDT
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 20741; Mon 12-May-86 14:10:50-EDT
Date: Mon, 12 May 86 13:01 EST
From: mike@a
To: common-lisp@su-ai.arpa
Subject: First Class environments in CL ??
Reply-to: beckerle@xx.lcs.mit.edu
Can you obtain a first-class
handle on a lexical environment in CL???
I do not see any operations which return an "environment"
anywhere in CLtL; however, the following discussion is
on page 323 with respect to the evalhook and applyhook feature.
"Furthermore, the 'env' argument is used as the lexical
environment for the operation; 'env' defaults to the null
environment."
I see no way to use this other than with the default environment.
Furthermore, if there were "environments" available, then
I'd expect to be able to pass them to EVAL, APPLY, etc.
We should do one of the following:
(1) eliminate the 'env' optional to evalhook/applyhook.
(2) provide a selector which extracts the current lexical environment
and returns it so that it can be stored as any first class object.
I prefer (1) since it makes compilation much easier and more effective.
Finally, to avoid confusion, In CLtL, there is a discussion of the
&environment keyword for macros. It specifically says that this
environment may not be complete, and should only be used with
"macroexpand" and is constructed by "macrolet". This is clearly
not the environment intended for use with evalhook.
...mike beckerle
∂12-May-86 1127 RAM@C.CS.CMU.EDU Void
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 12 May 86 11:27:41 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Mon 12 May 86 14:28:06-EDT
Date: Mon, 12 May 1986 14:27 EDT
Message-ID: <RAM.12206150618.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Subject: Void
In-reply-to: Msg of 12 May 1986 06:28-EDT from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
Date: Monday, 12 May 1986 06:28-EDT
From: Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
Re: Void
Date: Sun, 11 May 1986 21:06 EDT
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
The only places where a void expression may be legal are:
1] Any place where the value is immediately discarded: PROGN, etc.
2] Any place in a function that can return multiple values. In
addition to tail-recursive positions, this includes the protected
form of UNWIND-PROTECT and the values form for
MULTIPLE-VALUE-PROG1 when these forms are in such a
multiple-value position.
I'm sorry, but I find this completely ridiculous. Many valid
programs can be written which use `void' values in ways other than
this without being ill-formed.
Note that in either case, a void value may be illegal because the
result was declared to be of some other type:
(proclaim '(function frob-foo (foo) void))
(defun frob-foo (foo) ...)
(proclaim '(function make-foo ((member t nil)) foo))
(defun make-foo (frob-p)
(let ((foo (cons-a-foo)))
(if frob-p
(frob-foo foo)
foo)))
Suppose that FROB-FOO puts the FOO on the heap somewhere. Then suppose that
I have a function, CREATE-FOO, which is the only call of MAKE-FOO and is
defined as:
(DEFUN CREATE-FOO (STASH-P)
(COND (PUT-IN-HEAP
(MAKE-FOO T)
(VALUES NIL NIL))
(T
(VALUES (MAKE-FOO NIL) T))))
There's nothing ill-formed about the collection of programs which include
my program and yours.
Not true. I declared that MAKE-FOO *always* returns a FOO. VOID is
not a FOO, ever.
The programming problem you're worried about is a common one, but
the technique you're proposing for fixing it is just not
practical. This situation comes up in legitimate code (especially
when macros are involved) all the time.
I am aware of the macro problem that you describe, but I am not
convinced that it is significant. Any macro in Common Lisp which has
an implicit PROGN cannot get this effect by saving the value in a
variable, since the body might want to return multiple values. A
macro which knows nothing about its body must place it in a
multiple-value context. This is why there is a relation between
multiple-value contexts and legal VOID expressions.
Consider the following common situation: I have a macro MYBLOCK
which binds the variable * to the value of the previous
computation at the same level. For example:
(DEFMACRO MYBLOCK (&BODY FORMS)
`(LET ((* *))
,@(MAPCAR #'(LAMBDA (FORM) `(SETQ * ,FORM)) FORMS)))
In my reality, this macro assumes that each body form is not VOID.
I don't really see all these bad implications of adding a VOID type.
If you think that declaring things VOID crimps your style, then don't
do it. If the compiler barfs because you are using the value of
something that some other bozo declared VOID, then you can always say
(PROGN xxx NIL).
Rob
∂12-May-86 1217 Moon@SAPSUCKER.SCRC.Symbolics.COM First Class environments in CL ??
Received: from [192.10.41.223] by SU-AI.ARPA with TCP; 12 May 86 12:16:56 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 18106; Mon 12-May-86 15:13:59 EDT
Date: Mon, 12 May 86 15:13 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: First Class environments in CL ??
To: beckerle@MIT-XX.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 12 May 86 14:01 EDT from mike@ALLEGHENY.SCRC.Symbolics.COM
Message-ID: <860512151354.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 12 May 86 13:01 EST
From: mike@a
Can you obtain a first-class
handle on a lexical environment in CL???
Common Lisp only supports lexical closures as first-class objects. Each
implementation has (perhaps too much) freedom to implement the
environments embedded inside those closures however it wants. The
motivation for this freedom is to permit efficient compilation.
We should do one of the following:
(1) eliminate the 'env' optional to evalhook/applyhook.
(2) provide a selector which extracts the current lexical environment
and returns it so that it can be stored as any first class object.
I prefer (1) since it makes compilation much easier and more effective.
Compiled code does not set off *evalhook* and *applyhook*, so this 'env'
facility does not affect compilation in any way.
I believe the env argument to the function applyhook to be a typographical
error, since there is no meaningful way that that argument could be used.
Our implementation ignores it. I have not investigated, but I expect
every other implementation ignores it too.
It would be impossible for the evalhook function to operate correctly
without an env argument, since a form is only meaningful for evaluation
in some particular lexical environment. The book doesn't explain this
very well, but it should be apparent after studying the example on page
323. The only valid value for the env argument to the evalhook function
is, I believe, a value that was received as the second argument to a
function that is the value of *evalhook*, or nil.
Finally, to avoid confusion, In CLtL, there is a discussion of the
&environment keyword for macros. It specifically says that this
environment may not be complete, and should only be used with
"macroexpand" and is constructed by "macrolet". This is clearly
not the environment intended for use with evalhook.
I agree with you. It is permitted, but not required, to be the same
environment. In our implementation, it is the same environment in some
contexts and is something else in other contexts.
∂12-May-86 1557 NGALL@G.BBN.COM Re: First Class environments in CL ??
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 12 May 86 15:56:50 PDT
Date: 12 May 1986 18:57-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: First Class environments in CL ??
From: NGALL@G.BBN.COM
To: Moon@SCRC-STONY-BROOK.ARPA
Cc: beckerle@XX.LCS.MIT.EDU, common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]12-May-86 18:57:23.NGALL>
In-Reply-To: <860512151354.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 12 May 86 15:13 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
To: beckerle@MIT-XX.ARPA
Subject: First Class environments in CL ??
I believe the env argument to the function applyhook to be a typographical
error, since there is no meaningful way that that argument could be used.
Our implementation ignores it. I have not investigated, but I expect
every other implementation ignores it too.
Hmmm. Once again the meaning of FUNCTION and the semantics of
function application is ambiguous in CLtL. In the definition of
*applyhook* on pg. 322, it says
"When a function is about to be applied to a list of arguments, no
attempt is made to apply the function. Instead, the hook function is
invoked and is passed the function and the list of arguments as its
first and second arguments."
The naive reader (me) would assume that given a function call such as
(foo 1. 2. 3.)
that the apply hook function's first arg would be FOO and second arg
would be (1. 2. 3.). Such is not the case in VaxLisp (nor in
SCL). Instead, the first arg is FOO's function definition!
I admit that it is not clear from the above definition whether or not
"function" refers to "function name" (i.e., a symbol or a lambda
expression) or function definition (i.e., the thing associated with
the function name). But I do think that it is strongly implied that
the function name should be used, for the following reasons:
An implementation that passed the function definition to the apply
hook function would not be able to handle
(xyttdf 1.2. 3.)
where XYTTDF has no function definition. Instead of passing XYTTDF to
the apply hook function so that it can figure out what to do, it will
signal an error. I thought one of the uses of applyhook was to be
able to experiment with different ways of defining functions, for
example, funcalling an undefined function returns a continuation to be
evaled later when it has a definition.
Also, giving the apply hook function the function definition of a
function makes it useless as a way of overriding the functional
interpretation of a symbol, which I would assume is one of the primary
purposes of the apply hook. All the apply hook function sees is some
functional object (that may well be implementation dependent). It
can't find out the name that was actually used in the function call.
Finally, I believe the whole point of the ENV arg to APPLYHOOK is to
handle
(flet ((frab (a b) (+ a b)))
(frab 1 2))
so that the apply hook function is given three args: FRAB, (1 2), and
an env that contains a definition for FRAB. Without requiring that
the first arg to the apply hook function be the function name, then
the ENV arg to APPLYHOOK IS meaningless. Rather than being a typo., I
think it is more likely that the first arg to APPLYHOOK may be the
NAME of a function like FRAB above.
I think the apply hook stuff is in need of clarification in one
direction or the other, and I vote that it deal with function names as
opposed to function definitions.
-- Nick
∂12-May-86 1659 RAM@C.CS.CMU.EDU Void
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 12 May 86 16:59:41 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Mon 12 May 86 20:00:32-EDT
Date: Mon, 12 May 1986 20:00 EDT
Message-ID: <RAM.12206211157.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: Common-Lisp@SU-AI.ARPA
Subject: Void
In-reply-to: Msg of 12 May 1986 06:28-EDT from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
Let be rephrase the VOID proposal in terms of continuations,
hopefully making the semantics seem less arbitrary:
1] THE and the result type for a function type are statements about
the type of continuations with which it is legal to call a
function or evaluate an expression.
2] VALUES and the proposed VOID are only meaningful in this context
because they can only apply to continuations, not the values of
cells.
3] Stating that a continuation must be VOID is stating that the
continuation cannot reference its arguments *in any way*.
Excepting the funny cases of MULTIPLE-VALUE-PROG1 and UNWIND-PROTECT,
these statements are comparable to the previous definition, but a bit
stronger. The cases where I said that VOID should be erroneous are
those cases where it is obvious that the continuation for the
expression is not VOID.
Rob
∂12-May-86 1723 Moon@SAPSUCKER.SCRC.Symbolics.COM Re: First Class environments in CL ??
Received: from [192.10.41.223] by SU-AI.ARPA with TCP; 12 May 86 17:23:04 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 18315; Mon 12-May-86 20:20:28 EDT
Date: Mon, 12 May 86 20:20 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Re: First Class environments in CL ??
To: NGALL@G.BBN.COM
cc: beckerle@MIT-XX.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <[G.BBN.COM]12-May-86 18:57:23.NGALL>
Message-ID: <860512202002.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Your ideas about what applyhook could be used for are interesting, but
not what it was historically put in for. It was put in to make it
possible for a program that steps through execution of an interpreted
program to get control after all the arguments have been evaluated and
before the function receives control. A hook for the "fvaluation" of
the function in the car of the form would be useful, perhaps, but Common
Lisp doesn't have one now. It would be better to add a third hook for
this than to incompatibly change the meaning of applyhook. Note that
the fvaluation of the function has to happen -before- the arguments
are evaluated, because that's how EVAL finds out that it's dealing with
a macro or a special form.
I would be the first to admit that this stuff could benefit from
clarification.